Irrlicht 1.8.x segmentation fault under Windows

[merovingian]

I'm trying to update my project from 1.7.2 to 1.8.3.

Under Linux, I rebuilt my project (gcc 4.8.4) against 1.8.3, and it all works no problem.

Under Windows, I rebuilt (mingw 4.6.2) against 1.8.3, and it crashes with a seg fault the first time I try to call any IrrlichtDevice method.

Code: Select all

 
device = createDevice( foo, bar );
device->callAnything();
seg fault
 

createDevice() is not returning NULL.

So I swapped to mingw-w64 (4.9.3), and the behaviour was unchanged. Same seg fault. So I re-built Irrlicht with debug symbols, and stepped through the code - the seg fault is because the this pointer is corrupted (this=0x5) on the first device method call.

So then I built Irrlicht examples - they crash too. So it's not a problem with my application code.

So then I came here, because I am really puzzled - I presume I must be doing something wrong, since I don't see similar complaints from other people. But what I am doing is what has always worked for 1.7.2 and earlier. Any ideas?

[mongoose7]

If you are linking dynamically, you have to make sure you are loading the correct DLL. Search you disks for irrlicht DLLs or shared objects and delete them all. Then compile the library and application.

[CuteAlien]

It happens often when users mix up headers and dll's of different versions. With some luck you might even get an error-output for that in the console. So check the include path. And as mongoose7 proposed, do check which dll is really used.

[merovingian]

Thanks fellas.

I had already checked the CIrrDeviceStub::checkVersion() call, and it was happy that it was finding the 1.8.3 DLL. But that was the DLL I compiled, not the one that shipped with the SDK.

Your suggestions set me down the right path though - before posting here, I did indeed have the situation that my exe was finding the 1.7.2 DLL - I noticed that when I built my own DLL, because I still couldn't step into Irrlicht with the debugger. So I fixed it then. Then I could see the this pointer corruption.

So, initial seg fault was DLL version mismatch. Then once I had my own DLL, I still had a seg fault at the same call, but now I realise the reason is because there's something wrong with the DLL I built. I thought it was the same seg fault problem, but now I see how I confused myself.

I just restored the shipped 1.8.3 DLL - now my app, and the Irrlicht DLLs, are working.

So the only remaining mystery is why my debug DLL seg faults, but that's no blocker.

BTW, this community is great. Many thanks.