Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Solved (sort of): Access violation when calling RenderWindow.Display  (Read 2462 times)

0 Members and 1 Guest are viewing this topic.

chrisname

  • Newbie
  • *
  • Posts: 2
    • View Profile
It appears to be a bug in the CSFML 2.0 release candidate. I tried the following bare-bones code:
Code: [Select]
#include <SFML/Graphics.h>

int main()
{
sfVideoMode mode = { 800, 600, 32 };
sfRenderWindow* window = sfRenderWindow_create(mode, "SFML window",
sfResize | sfClose, NULL);
sfEvent event;
if (!(window))
return 1;
while (sfRenderWindow_isOpen(window)) {
while (sfRenderWindow_pollEvent(window, &event)) {
switch (event.type) {
case sfEvtClosed:
sfRenderWindow_close(window);
break;
default:
break;
}
}
sfRenderWindow_clear(window, sfBlack);
sfRenderWindow_display(window);
}
sfRenderWindow_destroy(window);
return 0;
}
and it segfaults and produces a core dump at the call to 'sfRenderWindow_display' (after a second or two). I'm going to try compiling the most recent snapshot myself in hopes that the bug has been fixed.

I have this (somewhat skeletal) class as part of an RPG I'm working on. Currently, unless I comment out the call to Window.Display() it will crash after a second or so. Sometimes there is no exception or any other kind of message displayed on the console window before the crash; it's just the usual "has stopped working" dialogue. Sometimes, however, the following message is displayed:
Quote
Unhandled Exception: System.AccessViolationException: Attempted to read or write
 protected memory. This is often an indication that other memory is corrupt.
   at SFML.Graphics.RenderWindow.sfRenderWindow_display(IntPtr CPointer)
   at SFML.Graphics.RenderWindow.Display()
   at RPG.Game.UpdateScreen() in c:\Users\Chris\Documents\Projects\RPG\Game\Sour
ce\Main.cs:line 47
   at RPG.Game.Run() in c:\Users\Chris\Documents\Projects\RPG\Game\Source\Main.c
s:line 56
   at RPG.Game.Main(String[] args) in c:\Users\Chris\Documents\Projects\RPG\Game
The exception is raised on the call to Window.Display() in the Game.UpdateScreen() method, and if I comment that line out, no exception/crash occurs.

I'm using the SFML.Net 2.0 release candidate (not the snapshot or Git version) x86 binaries on Windows 7 x86-64.

Code: [Select]
using System.Diagnostics;
using System.IO;
using SFML.Graphics;
using SFML.Window;

namespace RPG {
/// <summary> The game class. </summary>
class Game {
/// <summary>/ The window. </summary>
private RenderWindow Window;
/// <summary> The clock. </summary>
private Stopwatch Clock;
/// <summary> The INI parser. </summary>
private IniParser IniParser;

/// <summary> Constructs the <see cref="RPG.Game"/> class.
/// </summary>
/// <param name="path"> The game directory path. </param>
public Game(string path)
{
string prefs = Path.Combine(path, "Preferences.ini");
Console.WriteLine("{0}", prefs);
this.IniParser = new IniParser(prefs);
this.Window = new RenderWindow(new VideoMode(
uint.Parse(this.IniParser.Sections["Window"]["width"]),
uint.Parse(this.IniParser.Sections["Window"]["height"]),
uint.Parse(this.IniParser.Sections["Window"]["depth"])),
this.IniParser.Sections["Window"]["title"]);
this.Window.Closed += delegate {
this.Window.Close();
Environment.Exit(0);
};
this.Clock = new Stopwatch();
}

/// <summary> Handles the inputs. </summary>
private void HandleInputs()
{

}

/// <summary> Updates the screen. </summary>
private void UpdateScreen()
{
this.Window.Clear();
this.Window.Display();
}

/// <summary> Runs the game. </summary>
public void Run()
{
while (this.Window.IsOpen()) {
this.Window.DispatchEvents();
this.HandleInputs();
this.UpdateScreen();
this.Clock.Restart();
}
}

private static void ShowUsage()
{
string name = Environment.GetCommandLineArgs()[0];
Console.Error.WriteLine("Usage: {0} [options] <path>",
name);
}

/// <summary> The Main function. </summary>
/// <param name="args"> The command-line arguments. </param>
public static void Main(string[] args)
{
if (args.Length < 1) {
Game.ShowUsage();
Environment.Exit(1);
}
Game game = new Game(args[0]);
game.Run();
}
}
}
I don't think the rest of the program is relevant: I have written other classes, but the only one that's currently being used is the IniParser class and I don't think that's related to the problem. The rest is just base classes and interfaces. If you suspect the IniParser class is relevant, ask, and I'll post it.

Can anyone shed some light on this? I understand that it might not be a lot to go on, but any suggestions might help narrow down the problem (and more importantly, the solution).

[edit]
I've created a stripped down test program and the same error occurs with the following code:
Code: [Select]
using System;
using SFML.Graphics;
using SFML.Window;

namespace Test {
class Test {
private RenderWindow Window;

public Test()
{
this.Window = new RenderWindow(new VideoMode(640, 480, 32),
"Test");
this.Window.Closed += delegate {
this.Window.Close();
Environment.Exit(0);
};
}

public void Run()
{
while (this.Window.IsOpen()) {
this.Window.DispatchEvents();
this.Window.Clear();
this.Window.Display();
}
}

public static void Main(string[] args)
{
Test test = new Test();
test.Run();
}
}
}
This leads me to believe this is a bug in C SFML or SFML.Net.
« Last Edit: August 18, 2012, 10:20:29 pm by chrisname »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Solved (sort of): Access violation when calling RenderWindow.Display
« Reply #1 on: August 25, 2012, 05:36:17 pm »
Quote
I'm going to try compiling the most recent snapshot myself in hopes that the bug has been fixed.
Why didn't you do that before posting? :P
Laurent Gomila - SFML developer

chrisname

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Solved (sort of): Access violation when calling RenderWindow.Display
« Reply #2 on: August 28, 2012, 01:46:39 pm »
I prefer to assume that bugs are in my own code rather than in the libraries I'm using until I've exhausted everything else. I thought if it had been a known bug someone would point it out (I did check the bug tracker but I didn't find it).