SDL project dies on WinXP

This topic is 4269 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I got a new computer with XP (previously had Win98) and there seems to be some major problem with linking (either in SDL or mingw). The program crashes right away. When I run it with GDB it starts but crashes soon and tells something about 'libmsvcrt_a_iname'. I read that in VC++ you need to change the code generation for some lib to multi-threaded to avoid that. The problem is that I'm using Dev-C++... The project was working fine in Win98, so I guess there must be something different in XP.

Share on other sites
Have you recompiled and relinked all the objects?

Share on other sites
Quote:
 Original post by evolutionalHave you recompiled and relinked all the objects?

Yes.
Edit: I managed to fix one fatal bug that was crashing the project, but it still crashes during exit. The crash happens in one of the object class destructors, when the objects are deleted from the linked list. There is nothing really going on in that destructor, but it leads to a crash in libmsvcrt_a_iname.
The strange thing is that running normally without GDB crashes the program immediately, but GDB survives that.

[Edited by - Feidias on May 6, 2006 6:50:11 AM]

Share on other sites
It begins to look like SP2 is the "reason" for the crashes. I could test that by running the project with another computer which has SP1. SP2 has buffer overflow protection and if I understand it correctly there is an exception raised when this happens. It could explain why the program is crashed, there must be some overflow bugs in it.
The ironic thing is that GDB somehow prevents those exceptions which makes it impossible to see where it crashed:) I love programming:)

Share on other sites
I tried something else. I compiled another project also using SDL and it works. In both projects I noticed something quite interesting: member variables of classes are not reset to zero by default. I'm almost sure that this _should_ be a feature of C++ itself. If SP2 is preventing that it means that I have to check for a lot of code to see if it's initialized ok.

Share on other sites
C++ makes no promises to what any variable is initialized to. I know MSVS initializes variables to zero in the debug build, but it will warn you in release mode if something isn't set to zero. It is best practice to make sure all your variables are initialized to valid values.

Share on other sites
Quote:
 Original post by FeidiasI tried something else. I compiled another project also using SDL and it works. In both projects I noticed something quite interesting: member variables of classes are not reset to zero by default. I'm almost sure that this _should_ be a feature of C++ itself. If SP2 is preventing that it means that I have to check for a lot of code to see if it's initialized ok.

Nope, as far as I know if you write
int a;
a's value will be whatever memory happened to be floating there when it was given space.

Tested it.
#include <iostream>using std::cout;class uninit{public:	int a, b, c;};int main(int argc, char* argv[]){	uninit MyUninit;	cout << "'A' is " << MyUninit.a << ",\n";	cout << "'B' is " << MyUninit.b << ",\n";	cout << "'C' is " << MyUninit.c << ".\n";	return 0;}

Output:
'A' is 2009303637,
'B' is 2012824744,
'C' is 7.

Share on other sites
There was a bug in file loading which probably read one past the end of file. Now it starts to the title screen. But when I run with GDB it now crashes right away.

GDB is saying:
warning: Invalid address specified to RtlFreeHeap

Then it crashes in ifstream.close(); in read file routine. I think GDB is doing something weird and SP2 doesn't like it, or another way around. If it seems to run ok normally then I guess it doesn't matter if it doesn't run in GDB.

Share on other sites
I've come to a conclusion that there is nothing wrong with the system. SP2 is just stopping in array overflow bugs and it's actually a good thing, because those went unnoticed in Win98. Only problem left is the differences when run with GDB or normally. It seems that you can't use GDB to track _some_ bugs, because GDB can survive them (for some unknown reason).