SFML community forums
Help => Graphics => Topic started by: ritave on January 14, 2010, 04:48:10 pm
-
Since yesterday's revisions, it's not possible to do graphical applications, it's probably somewhere in RenderWindow initialization. When debugging the MVS says it's something accessing pointer 0x00000000. Narrowing the problem, my server application (only system and network parts of SFML) still works fine on the same libs. And MVS log points to sfml-graphics.dll
Some more library loading
'Client.exe': Loaded 'C:\WINDOWS\system32\mcd32.dll'
'Client.exe': Unloaded 'C:\WINDOWS\system32\mcd32.dll'
First-chance exception at 0x0046c246 (sfml-graphics.dll) in Client.exe: 0xC0000005: Access violation writing location 0x00130008.
First-chance exception at 0x00000000 in Client.exe: 0xC0000005: Access violation reading location 0x00000000.
The last one repeating a lot.
Now why in intialization of window? Since I've made a breakpoint in init function of my app, and it never got reached, neither in debug noir release version, also I don't have any other classes used anywhere from sfml-graphics.dll
Also can't be fault on my part - it worked with older libs, and I have no pointers anywhere in my code.
-
Is it sfml2 or trunk? At which revision did it break exactly? Have you tried the latest one? Have you tried the samples?
-
It's sfml2. I update once every two-three days, but the one I updated to was 1353. Yeah, I've updated to the latest one. I tried the pong example on newest revision - the problem is the same.
-
Have you tried revision 1352 to make sure that 1353 is the faulty one? What OS / compiler do you use?
-
Microsoft Visual 2008, Windows XP 32-bit Service Pack 3.
I checked svn logs, and only revisions (according to files changed) since January 11 (since I updated somewhere at that time or later) that could be the problem are: 1344, 1345, 1353. The others changed mostly DSFML and CSFML, and things not connected to graphics (not counting sprites or joystick, as I don't have any in my app)
-
I know, I checked the logs too. That's why I'm asking you if you actually tested those revision to find the good one :)
-
Nope... Should I? :P
-
It would help me a lot :)
-
There we go! It seems that 1344 was faulty, I checked the older one which had something to do with windows, and if I didn't make a mistake it was 1322 which worked fine.
-
Well, if 1344 is the one, why didn't you check 1343 instead of 1322? ;)
Because there was almost no modification in revision 1344.
-
Because it doesn't change window class, but I forgot that window has it's own input. Wooops :/ I'll check it.
-
We don't care about what a revision changes, if 1343 works then we are sure that 1344 is the faulty one, if it doesn't work then we are sure that it is not. I just need to find revision X, where X-1 worked and X not, whatever their log say :)
-
But that's a lot more work involved, we should check only the ones with changes that have an impact on a window, that way - it was 4 revisions instead of 30
-
Of course, but once you've found a good candidate you must check the previous revision to be sure. I thought that you were at this point when you said "It seems that 1344 was faulty" -- that's why I suggested to test 1343 :)
-
Well then, I checked the 1343, and it is the 1344 being the faulty one.
-
Great, thank you a lot.
This is strange because what I did in revision 1344 was to put back 3 lines of code that I had moved in a previous revision :?