A SJIJ-based compiler makes my app crash

[dobbi10k]

Hi,
I'm currently developing a 2D game engine based on SFML. I just rewrite my input code to be multithreaded (e.g. for not having a game stop when moving a window) and hence updated my compiler to GCC 4.7-SJIJ,  because I wanted the "native" C++11 threading code. When I tried to run my app though, it crashed immediately (yes, I used a version of SFML compiled with SJIJ). I got an older revision of the engine, didn't work either. So I tracked down the crash to the point where my "CRender" class is initialized, which has a sf::RenderWindow as a member variable (the actual window isn't created yet). I used my old 4.6-DW2 compiler again and it worked. Out of curiosity I downloaded 4.8-SJIJ and 4.6-SJIJ, too. Both crash the app. I'm positively sure it's the SJIJ error handling, because both 4.4-DW2 and 4.6-DW2 work just fine.

The exact error is 0xC0000005. I did some googling and this error often occurs when using not yet fully initialized variables or something. Anyway from my knowledge this is the access violation error, I'm kinda confued though, because it only occurs with SJIJ.

I hope I made my point and that anyone can possible help me. Of courdse compiling MinGW 4.7 with DW2 would solve the issue for now, I feel that is more of a dirty work-around and not an actual solution.

Regards,
dobbi10k

[Laurent]

Where did you get a version of SFML compiled with gcc SJLJ? Is it SFML 2 or 1.6? Have you used the debugger to know more about the crash? Have you tried a minimal example with only a sf::RenderWindow in a main()?

[dobbi10k]

Oops, actually i intended to include all neccessary information in the thread, but i guess I'm still kinda fuzzy from last night
It's SFML2, as 1.6 doesn't work with my ATi card... I tried both the RC you provide on the download site as well as compiling the latest snapshot.
Yes, I tried the minimal example, crashes, too, unfortunately.
I'm going to try to get a debugger in one of my compilers working, as the 4.6 one refused to help me...

EDIT: a test app works with 4.6 SJLJ, but not with 4.7 nor 4.8, weird... (crashes with 0xC0000005)
I'm now trying to compile a newer MinGW with dwarf2 and trying to get a debugger work

[Laurent]

a test app works with 4.6 SJLJ, but not with 4.7 nor 4.8

Which one did you use to compile SFML?

Where did you get your MinGW SJLJ versions?

Can you show what "gcc -v" outputs for both the version which works (4.6) and the one that crashes (4.7)?

[dobbi10k]

I tried compiling with all three, unfortunately it didn't help.
I downloaded the builds here. They aren't official, I know, but I've never had any problems with those...

gcc --version outputs what you'd expect it to:
4.6:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
4.7:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.7.1 2012
0425 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
4.8:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.8.0 2012
0425 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I "fixed" the problem, by rewriting my code to use your threading library and constructing a condition_variable class and then compiling with 4.6-DWARF2. Still I feel it's a dirty work-around

[dobbi10k]

I think I fixed the problems. It wasn't actually about SFML, but about how the Compilers initialized pointers.
While the dw2 Compiler sot them to 0, the others set them to 1, which broke my code. Manually adding ptr=0 in the constructor solved it.

[Laurent]

I don't think that the compilers "broke your code", if you had uninitialized pointers then your code was already severely broken anyway

[dobbi10k]

The pointer was initialized just in tje next function. For reusability I had to (bool)ptr in an if condition though. I expect unitiqlized pointers to return false as the book sqys. Obviously that's not the case...

[Laurent]

I expect unitiqlized pointers to return false as the book sqys. Obviously that's not the case...

A book that teaches to keep uninitialized variables and rely on their default values seems like a bad one. Whether the standard specifies the behaviour or not (and I don't think it does), it's never a good idea to leave native types uninitialized.

[dobbi10k]

I didn't literally mean 'like the book says', it was rather considered a pun (a Little Red Riding Hood joke; I don't even have a book about C++).
In my code I have:

Code: [Select]

CStatemanager::Initialize(); //it's a singleton and I made it threadsafe by not using lazy instatioation and placing this code in a part of my grogram that is guaranteed to be st
CStateManager& StateManager = CStateManager::Instance();
StateManager.PushState(Game->States());
StateManager.ChangeState(StartState); //where StartState is #defined

CStateManager::CStateManager()
{
    Running = true;
    FLimiter = true;
    ReturnCode = 0;
    ActiveState = 0;
}

void CStateManager::ChangeState(unsigned short int Identifier)
{
    if (ActiveState) ActiveState->Cleanup();
    ActiveState = States[Identifier];
    ActiveState->PreInit();
}
As you can see the ActiveState pointer would normally inizialized just after object creation, but I wanted to make ChangeState actually reusable, so I included the Cleanup() part. To prevent it being executed before any state was specified I added the if statement. Now it seems the dw2 compiler initializes the pointer to 0, which is why the code worked as intended. The other Compilers initialized it to some other value, which made ((bool)ActiveState) true and hence broke my code. The manual initialization to 0 in the constructor itself fixed the Problems though. I don't think this was so much of an design error, but anyway, it's fixed now