SFML community forums
Help => Graphics => Topic started by: fazeli on April 26, 2010, 10:44:06 pm
-
(Complete beginner)
Trying to go through the tutorials, stuck on "Graphics - Using render windows" (http://sfml-dev.org/tutorials/1.6/graphics-window.php). It seems the App.Clear() and App.Clear(sf::Color(200, 0, 0)) are both causing
First-chance exception at 0x00434155 in SFML_GraphicsWindow.exe: 0xC0000005: Access violation reading location 0x43960010.
Unhandled exception at 0x00434155 in SFML_GraphicsWindow.exe: 0xC0000005: Access violation reading location 0x43960010.
After commenting out the App.Clear sections, the code runs without exception.
I've tried going through the source with the debugger but as I mentioned I am a beginner.
Any suggestions would be greatly appreciated. Thank you.
-
Could you show the code?
-
Sorry my bad. The code that was being used is the same as the one in the tutorial in this file http://sfml-dev.org/tutorials/1.6/sources/graphics-window.cpp. I have included a copy here below stripped of comments.
#include <SFML/Graphics.hpp>
int main() {
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
while (App.IsOpened()) {
sf::Event Event;
while (App.GetEvent(Event)) {
if (Event.Type == sf::Event::Closed)
App.Close();
if (Event.Type == sf::Event::KeyPressed) {
if (Event.Key.Code == sf::Key::Escape)
App.Close();
if (Event.Key.Code == sf::Key::F1) {
sf::Image Screen = App.Capture();
Screen.SaveToFile("screenshot.jpg");
}
}
}
App.Clear(sf::Color(200, 0, 0));
App.Display();
}
return EXIT_SUCCESS;
}
Additional Information.
I've linked the following files: sfml-system-s.lib sfml-graphics-s.lib sfml-window-s.lib
There are no additional .dll in the directory that the file is being executed in as I don't believe I need as I am using the static libraries.
Newly discovered. Oddly enough when I link to sfml the static-debug versions of the libraries files, the code runs properly. However, compiling results in many warnings similar to the following.
1>sfml-system-s-d.lib(Platform.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'C:\SFML-1.6\lib\sfml-system-s-d.lib' or at 'c:\Documents and Settings\user\My Documents\Visual Studio 2005\Projects\SFML_GraphicsWindow\debug\vc80.pdb'; linking object as if no debug info
-
What's the -s, did you rename your dlls?
-d is for debug and nothing there is the release ones.
Debug version:
sfml-graphics-d.dll
Release version:
sfml-graphics.dll
BTW, I would fix your indentation blocks because it's hard as hell to tell where your nests are.
-
-s = static, which as I understand it means the dlls do not have to be copied to current executable directory nor do they need to be renamed. those libs without the -s mean dynamic in which case you have to copy the dll to the current directory (my understanding maybe incorrect) but I believe I read it in http://www.sfml-dev.org/tutorials/1.6/start-vc.php
yea the paste that I did resulted in poorly readable code, but I figured it was short enough that there was no need to repaste.
-
Oh that's right.
Maybe you need to set your project for release?
-
Could you please elaborate on what you mean by "set your project for release"? I'm very new to MSVS, so please overlook my ignorance.
-
[OFF] You can use the Code and /Code tags ;)
// Like this
[ON]
Could you please elaborate on what you mean by "set your project for release"? I'm very new to MSVS, so please overlook my ignorance.
There should be a "release" and a "debug" configuration of your project. Make sure that you link against debug libraries in the debug config, and against release libs in the release config. See http://msdn.microsoft.com/en-us/library/wx0123s5.aspx
Another thing is the order of linking. It is mentioned somewhere in the SFML tuts that if A lib depends on B, you should link first A, then B. I don't know what is the effect of mixing the order, I have never tried it :) But maybe this is the cause. If not, I would check whether the creation of sf::RenderWindow was successful. Can't be sure :)
-
#include <SFML/Graphics.hpp>
int main() {
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
while (App.IsOpened()) {
sf::Event Event;
while (App.GetEvent(Event)) {
if (Event.Type == sf::Event::Closed)
App.Close();
if (Event.Type == sf::Event::KeyPressed) {
if (Event.Key.Code == sf::Key::Escape)
App.Close();
if (Event.Key.Code == sf::Key::F1) {
sf::Image Screen = App.Capture();
Screen.SaveToFile("screenshot.jpg");
}
}
}
App.Clear(sf::Color(200, 0, 0));
App.Display();
}
return EXIT_SUCCESS;
}
Thank you for all the suggestions! The code tags were most helpful. I'll hunt down the statements about the order of the libs, but I had thought that the order likely wouldn't matter because of #ifdefs and#defines but I'll double check.
I had thought that sf::RenderWindow::isOpened() would check if the render window had been created successfully but I'll read about that in the documentation. I was also confident that it was being created successfully (as well as opened and all that) because the "Unhandled Exception" problem did not occur when sf::RenderWindow::Clear() was commented out and the code executed as described.
-
I was also confident that it was being created successfully (as well as opened and all that) because the "Unhandled Exception" problem did not occur when sf::RenderWindow::Clear() was commented out and the code executed as described.
Sorry, I tend to say really stupid things :)
Well... maybe a call stack would show the source of the problem.
-
I'm sure the code originally posted without proper formatting didn't help the matter.
I haven't leaned the proper use of the debugger yet but here's my Call Stack when the -s-d.lib were changed back to -s.lib
(yellow arrow) SFML_GraphicsWindow.exe!sf::RenderTarget::Clear() + 0x5 bytes C++
(green arrow) > SFML_GraphicsWindow.exe!main() Line 41 C++
SFML_GraphicsWindow.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
SFML_GraphicsWindow.exe!mainCRTStartup() Line 414 C
kernel32.dll!7c817077()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
-
Hmmm.. I don't know if anyone can see the problem from this, but I can't. Here is what I suggest:
- Switch back to debugging libraries.
- Start the program in debug mode (I assume you are using some kind of IDE, and that feature is available)
- Put a breakpoint just before the App.Clear(); statement
- now when the arrow points to that statement (indicating that this is the next statement to execute), use "step in"
- Somewhere it will segfault. Probably in a function, so remember that function, and start all over again this procedure, but step in that function.
- Always advance a single step at a time in the function where you don't know where is the problem. (Except of course if it is a loop which cycles 100000 times or things like that :))
If you do just as this, eventually you will find yourself at a single statement throwing segfault. At that point, copy the callstack, and the current line you are on.
OR
wait for some other responses :)
-
Sounds like a plan to me and has the added benefit that I don't have to read on how the MS VS 2005 debugger works!
-
Didn't seem to add any information for me, although it could hit me in the face and I might still not know. Here's the information that I received.
Message from application as it was running.
Unhandled exception at 0x0042f835 in SFML_GraphicsWindow.exe: 0xC0000005: Access violation reading location 0x43960010.
(circled yellow arrow) SFML_GraphicsWindow.exe!sf::RenderTarget::Clear() + 0x5 bytes C++
(green arrow) SFML_GraphicsWindow.exe!main() Line 41 C++
SFML_GraphicsWindow.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
SFML_GraphicsWindow.exe!mainCRTStartup() Line 414 C
kernel32.dll!7c817077()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
Disassembly window reads
// Clear the screen with red color
App.Clear(sf::Color(0, 255, 0));
(red arrow) 0042E6B6 push 0FFh
0042E6BB push 0
0042E6BD push 0FFh
0042E6C2 push 0
0042E6C4 lea ecx,[ebp-458h]
0042E6CA call sf::Color::Color (42B12Ch)
0042E6CF push eax
0042E6D0 lea ecx,[ebp-84h]
0042E6D6 call sf::RenderTarget::Clear (42B2D5h)
// Display window contents on screen
App.Display();
(green arrow) 0042E6DB lea ecx,[ebp-314h]
0042E6E1 call sf::Window::Display (42B762h)
Thanks for the help thusfar but it's not too important for me right now if this is an error that can't be reproduced, as I am content with using the -s-d.libs as I learn.
-
I wrote a little program (finished tonight), and I used the graphics module in it. I'm in Ubuntu Karmic, using libmesa. And a lot of time, some radeon function throws a segfault right after I close the application (I believe this is a bug in libmesa). So maybe (just maybe) the problem is in your environment (driver, etc.), and not in SFML. I'm not enough here, I guess. Sorry :S
But if you don't want to hunt down memory corruptions, here is a couple things you could try:
-test if other Graphics-related things work well (drawing, moving a view, etc.)
-try other window sizes / resolutions
-update your driver
-try it on different compilers (who knows...)
-worst-case scenario: update to sfml2
(+1: reboot your computer :D)
Anyway, I think Laurent should read this topic, maybe he can ask the right questions :)
-
Several users have a problem with sf::RenderTarget::Clear. However it can only be a driver or OpenGL problem, all this function does is to call glClearColor and glClear. It can't crash.
-
Workaround: check your view's dimensions (width, height, position), and draw a rectangle... nothing better came into my mind :)
-
Thanks for the info Laurent and the help and suggestions nulloid. Just one further question Laurent, is it normal for those experiencing the problem to have it work out when using the -d.libs?
-
Just one further question Laurent, is it normal for those experiencing the problem to have it work out when using the -d.libs?
No, unless they compile in debug mode.
-
did you find a fix yet?
-
I can't find a fix if I don't find the problem first ;)
-
I'm running with the 1.5 packages installed from synaptic on ubuntu and I'm getting the crash too. I'm not linking against the debug libraries, just the regular ol static libraries.
When I call window.Clear() I get a seg fault. When I call glClearColor(...) followed by glClear(GL_COLOR_BUFFER_BIT) it runs just fine. Until someone figures out why window.Clear() is dying on me I'll jsut use glClear as a workaround.
:?
Edit:
I played around a little bit and have no idea what the problem is. I looked at the source and I can't see anything that could be going wrong. I tried remaking the exact code that Clear calls, but when I do that it runs fine.
bool Activate(sf::RenderWindow& App, bool Active)
{
if (Active)
return App.SetActive();
else
return false;
}
void Clear(sf::RenderWindow& App, const sf::Color& FillColor)
{
if (Activate(App, true))
{
glClearColor(FillColor.r / 255.f, FillColor.g / 255.f, FillColor.b / 255.f, FillColor.a / 255.f);
glClear(GL_COLOR_BUFFER_BIT);
Activate(App, false);
}
}
int main()
{
// Create the main rendering window
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
// Start game loop
while (App.IsOpened())
{
// Process events
sf::Event Event;
while (App.GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
App.Close();
}
// Clear the screen (fill it with black color)
//App.Clear(sf::Color(0, 0, 0));
// Uncommenting the line above crashes, yet the one below works fine.
Clear(App, sf::Color(0, 0, 0));
// Display window contents on screen
App.Display();
}
Baffling. I did notice that SFML_DEBUG was defined, even though I'm not linking against the debug libraries as far as I know.
game : *.cpp *.h
g++ -o game \
main.cpp Border.cpp Game.cpp Widget.cpp \
-I/usr/local/include/luajit-2.0 -lluajit-5.1 \
-lsfml-graphics -lsfml-window -lsfml-system -Wall -Weffc++ -Wextra \
-Wshadow -Wformat-nonliteral -Wformat-security -Winit-self -Wundef
-
Thanks a lot for your help :)
I did notice that SFML_DEBUG was defined, even though I'm not linking against the debug libraries as far as I know.
How did you notice that SFML_DEBUG is defined?
Can you try adding -DNDEBUG to your command line and see if the crash is still there?
-
While I was reimplementing the Clear method I noticed GLCheck was a macro that only does anything if SFML_DEBUG is defined. I omitted it in the code snipped I posted below though. When nothing I did crashed, I though "maybe the code the GLCheck calls is what's crashing" but GLCheck only did anything if SFML_DEBUG was defined, so I just threw in a quick check to see if it was:
#ifdef SFML_DEBUG
std::cout << "Test!" << std::endl;
#endif
When I started running my program I was spammed with "Test!" After seeing that it was actually defined I tried copying and pasting the full contents of the GLCheck macro and wrapping the glClear and glClearColor calls in it, but that still didn't crash it.
Edit: Adding -DNDEBUG didn't have any effect. I'm going to try compiling the source and using those libraries when I get home from work today and see if that gives me better luck than the packages from synaptic. I'll let you know what happens.
-
So I removed the packages I was using from synaptic, and instead downloaded the trunk and built it from there, and now it seems to work. In order to get it to compile though I had to get a few extra libs that I didn't seem to have before. If I didn't have those libs, I don't see how the 1.5 packages could have run properly either (and they didn't include them as dependencies) so I wonder if that's the problem.
-
Hmm, weird. Which packages was it?
-
I now have to link against GL, and I needed to install and link against glfw in my project. My makefile went from what you see in on of my previous posts to the following:
game : *.cpp *.h
g++ -o game \
main.cpp Border.cpp Game.cpp Widget.cpp \
-I/usr/local/include/luajit-2.0 -lluajit-5.1 \
-L/home/alex/src/cpp/sfml/lib/ -isystem/home/alex/src/cpp/sfml/include/ \
-lGL -lglfw \
-lsfml-graphics-s -lsfml-window-s -lsfml-system-s -Wall -Weffc++ -Wextra \
-Wshadow -Wformat-nonliteral -Wformat-security -Winit-self -Wundef
(I have -isystem instead of -I because otherwise I get a bunch of compiler warnings about things like destructors in sfml not being marked virtual and stuff)
-
I now have to link against GL
Because you have OpenGL code in your application ;)
and I needed to install and link against glfw in my project
This one is definitely not necessary. I guess it links itself to the actual library that you need, so it works. What errors do you get without glfw?
-
Because you have OpenGL code in your application ;)
Nope :)
The only openGL code I had was the call to glClearColor and glClear, both of which have been removed. It complains about gl calls in sfml
http://pastebin.com/Ub0BQU4c
This one is definitely not necessary. I guess it links itself to the actual library that you need, so it works. What errors do you get without glfw?
If I include GL, then I just get these:
http://pastebin.com/24fDLs6M
to compile this, I'm just just the sample program from the tutorial:
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
int main()
{
sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
while (App.IsOpened())
{
sf::Event Event;
while (App.GetEvent(Event))
{
if (Event.Type == sf::Event::Closed)
App.Close();
}
App.Clear();
App.Display();
}
}
-
I'm using Linux Mint, which is basically the same as Ubuntu and I encountered this same problem, with all my SFML-based programs working fine until I recompiled them. It turns out the earlier version (1.5) had installed its libraries to /usr/lib, whereas version 1.6 had installed its libraries to /usr/local/lib. I assumed this meant that my app was being linked to the old libs (perhaps meaning the wrong dynamic libs are used), and the problem somehow stemmed from that. Anyway, switching to root and eliminating the version 1.5 libraries has solved the problem.
-
Ah, you're right. This is something that I always forget :)
-
And the best is to call glClear() directly, because of one flop performance boost :)
I am using SMFL just for event handling and the window. The rest is raw OpenGL. Well, but I am experienced.
p.s. i Don't have problems with window::Clear()
-
I had the same problem.
This is how i fixed it... It's stupid, really...
Under VC++ 2008 Project > Properites > Configuration Properties > General
I had this "$(SolutionDir)$(ConfigurationName)" in Output directory field.
So I typed there "Debug". There's field below with "$(ConfigurationName)", so i typed "Debug" too. And it works now... But only under debug mode.