Jump to content
  • Advertisement
Sign in to follow this  
Tertsi

Very weird crash on a few PCs with this C++ code but not with most PCs

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been trying to figure out what's making this code to crash a Windows program on a few modern computers with WinXP 32 bit which easily meet the program's requirements but don't do any harm to most? computers. Here's the code which gets executed before the crash and a few lines of code which don't get executed on those computers. This crash just doesn't make any sense. I appreciate any effort to help with this problem.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
	MSG			msg;
	WNDCLASSEX	wndclass;
	ZeroMemory(&msg, sizeof(MSG));
	ZeroMemory(&wndclass, sizeof(WNDCLASSEX));

	// Set up window class
	wndclass.cbSize = sizeof(WNDCLASSEX);
	wndclass.lpszClassName = CLASS_NAME;
	wndclass.lpfnWndProc = WinProc;
	wndclass.hInstance = hInstance;
	HInstance = hInstance;
	wndclass.hCursor = NULL;
	wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
	wndclass.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH);

	if(!RegisterClassEx(&wndclass))
	{
		MessageBox(HWND_DESKTOP, "Failed to register the window class. Aborting...", "Error!", MB_OK);
		return 0;
	}

	if(!(hWnd = CreateWindow(CLASS_NAME, WINDOW_NAME, WS_OVERLAPPED | WS_DISABLED, 0, 0, windowwidth, windowheight, NULL, NULL, hInstance, NULL)))
	{
		MessageBox(HWND_DESKTOP, "Failed to create the window. Aborting...", "Error!", MB_OK);
		return 0;
	}

	//ShowWindow(hWnd, nCmdShow);
	//UpdateWindow(hWnd);
	ShowCursor(false);

	dolostdevice = true;
	BoNgame	*game = new BoNgame();

// Nothing after this gets executed

// Start of The BoNgame class constructor
BoNgame::BoNgame()
{
   optionsref = new BoNoptions();
// Nothing after this gets executed

// Start of The BoNoptions class constructor
BoNoptions::BoNoptions()
{
	obtainsettings();
// Nothing after this gets executed

void BoNoptions::obtainsettings()
{
	string line;
	{
		ifstream in("options.ini");
		if(!in.is_open())
		{
			load_defaults();// Can't open file, load defaults.
                    // Nothing after this gets executed


void BoNoptions::load_defaults()
{
// The following three commented lines get executed if I uncomment them
	// ofstream outlog("BoNoptions_Load_defaults_extralog.txt");
	// outlog << "Output test ok." << endl;
	// outlog.flush();
// The below lines never get executed
	mousesens = 1.0f; // float
        sfxvolume = 0; // int
        musicvolume = 0; // int


[Edited by - Tertsi on August 19, 2005 1:11:36 AM]

Share this post


Link to post
Share on other sites
Advertisement
First, you never call "delete game" in your code =\ memory leak! You could even just do this:


BoNgame();


Which creates a nameless instance of your game class - better than allocating it on the heap anyway.

Next, you might want to look into ZeroMemory(), because "wndclass = {0};" doesn't make all of its elements NULL.


ZeroMemory(&wndclass, sizeof(WNDCLASSEX));


Now, you have "HInstance = hInstance;".. Why? You don't need to keep this value around, and even if you did need to use it somewhere, you could get it like this:


HINSTANCE hInstance = reinterpret_cast<HINSTANCE>(GetModuleHandle(0));


I'm sure there are other places where your code could have broken, but this is all I see so far. (Sorry for throwing in some style tips)

Share this post


Link to post
Share on other sites
To me, this seems like it could very well be the case where the this pointer, is NULL, thus the instance itself doesn't actually exist. You can print out stuff to a log file, but the moment you access a member, you're actually accessing this->member, which means a pointer needs to be dereferenced. If the pointer is NULL (or bad in general), you'll most certainly get a crash. Try

outlog << "BoNoptions::this == 0x" << this << endl;

right before your outlog.flush(); statement, and see what it comes up with. Of course, I haven't seen this within a constructor before, however. Just in general code. Something like:

CSomeClass* pInstance = GetAnInstance(); //Let's say that this returns NULL
pInstance->SomeMemberFunction(42); //This function executes just fine.
//The program only crashes as soon as
// the function tries to access any
// member variable.

If that is indeed the direct cause of the crash, I don't currently know what would be the indirect cause of that, though. Maybe some of Wavarian's suggestions will correct something.

Share this post


Link to post
Share on other sites
Wavarian I do delete the BoNgame(). The windows function doesn't end there, just like the comments say. I use new and delete so I could call game->update_game();.

That ZeroMemory(&wndclass, sizeof(WNDCLASSEX)); might just help.

Agony thanks for the this pointer tip, I'll look into it.

[Edited by - Tertsi on August 17, 2005 9:15:14 AM]

Share this post


Link to post
Share on other sites
The program is still crashing on some computers because of the problem although BoNoptions::this == 0x00C918D8 when tested on one of those computers so the direct cause of crash wasn't even the this pointer.

Share this post


Link to post
Share on other sites
Tertsi,

I came across a similar problem with the g++ compiler. I didn't have any problems when running the code in Linux, OSX and some WinXP/MinGW machines. However one machine, with a DFI Lanparty mobo, crashed in mid-loop. It would just cut out and re-boot. I initially thought that it could be faulty ram or a faulty mobo, but I tested these thoroughly and they were OK.

My experience with most OS's is that you will get a segfault (or bus failure) message when a pointer is out of scope, but when the machine completely cuts out, there is likely to be a memory allocation problem in RAM.

When I tracked the problem, I found that the crash happened within a particular loop, where I had inadvertently assigned a time_t (or size_t, I can't remember) to an unsigned int variable.

It could be that there is something like this going on which is causing a memory allocation error in the RAM of some machines. Have you tried to isolate the precise location of failure (by cout << (...) << endl;) statements in the code, and then checked the memory allocation there?

Needless to say I am now absolutely hygenic when it comes to typing variables.

--random

Share this post


Link to post
Share on other sites
Well that isn't so similar really, I know exactly the point where it crashes so no need to add output everywhere. However I see absolutely no possibly broken code (and it seems none of you does either) in the few lines of code which get executed before the crash.

Share this post


Link to post
Share on other sites
Tertsi, I would say this: Your debugger may be lying to you when it gets to load_defaults and then crashes. I feel like the crash is that it can't load a file named "options.ini" (probably because of a path problem), and so all afterward becomes bogus.

If you can verify that "options.ini" is loaded (say print out first 16 bytes or something), then I will be wrong. My guess is path problem.

Share this post


Link to post
Share on other sites
just check


if(!in)
{
//could load the file the STL overloadsthe ! operator for checking if the file could be opened properly
}

Share this post


Link to post
Share on other sites
Quote:
Original post by ajas95
Tertsi, I would say this: Your debugger may be lying to you when it gets to load_defaults and then crashes. I feel like the crash is that it can't load a file named "options.ini" (probably because of a path problem), and so all afterward becomes bogus.

If you can verify that "options.ini" is loaded (say print out first 16 bytes or something), then I will be wrong. My guess is path problem.


I wouldn't think that the problem is a file loading one, as, if you are using the same code on each machine, the files should be there. I still think that there is a type problem.

I noted that you've got bools, ints, floats, etc in the vicinity of the fault. Have you checked these? For instance are there any special types for sound or music? Could there be some problem with access to sound cards on some of the machines? There is not enouguh code to tell whether the return types are compatable, could this be a cause?

Another possibility is that a pointer of local scope is accessed by some other part of your program, such as *game. Have you tried makng them static (near the failure point only) just to see what happens?

--random

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!