Author Topic: SFML Accessing null pointer (Read 5905 times)

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

Code: [Select]


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.

Laurent · « **Reply #1 on:** January 14, 2010, 04:59:19 pm »

Is it sfml2 or trunk? At which revision did it break exactly? Have you tried the latest one? Have you tried the samples?

ritave · « **Reply #2 on:** January 14, 2010, 05:21:58 pm »

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.

Laurent · « **Reply #3 on:** January 14, 2010, 05:30:49 pm »

Have you tried revision 1352 to make sure that 1353 is the faulty one? What OS / compiler do you use?

ritave · « **Reply #4 on:** January 14, 2010, 05:41:59 pm »

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)

Laurent · « **Reply #5 on:** January 14, 2010, 05:47:14 pm »

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

ritave · « **Reply #6 on:** January 14, 2010, 06:02:38 pm »

Nope... Should I?

Laurent · « **Reply #7 on:** January 14, 2010, 07:21:38 pm »

It would help me a lot

ritave · « **Reply #8 on:** January 14, 2010, 08:21:16 pm »

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.

Laurent · « **Reply #9 on:** January 14, 2010, 09:07:18 pm »

Well, if 1344 is the one, why didn't you check 1343 instead of 1322?

Because there was almost no modification in revision 1344.

ritave · « **Reply #10 on:** January 14, 2010, 09:17:10 pm »

Because it doesn't change window class, but I forgot that window has it's own input. Wooops :/ I'll check it.

Laurent · « **Reply #11 on:** January 14, 2010, 09:21:12 pm »

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

ritave · « **Reply #12 on:** January 14, 2010, 09:27:37 pm »

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

Laurent · « **Reply #13 on:** January 14, 2010, 09:30:26 pm »

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

ritave · « **Reply #14 on:** January 14, 2010, 09:38:58 pm »

Well then, I checked the 1343, and it is the 1344 being the faulty one.