if (__onexitbegin) {
_PVFV * pfend = __onexitend;
while ( --pfend >= __onexitbegin )
/*
* if current table entry is non-NULL,
* call thru it.
*/
if ( *pfend != NULL )
(**pfend)();
}
Crash on exit :(
Author
For some reason, my program has decided to start crashing every time I quit out. (either via the code or using the close window button). I used the debugger and traced the fault to the CRT0DAT.C file and this section of code:
Now, I''m anything but a good windows programmer so I have no idea what it''s trying to do here, but it runs through the while loop twice, then it attempts to exit the loop and crashes.
the debug window reports the following:
First-chance exception in shootemup.exe (NTDLL.DLL): 0xC0000005: Access Violation.
The program ''D:\SHOOTER\shootemup\Debug\shootemup.exe'' has exited with code 0 (0x0)
Anyone know what this relates to? Or perhaps a good way to fix it?
That is ms''s code. It''s way more likley your code has done something that causes the crash. Post some of your init code and shutdown code
Author
That''s just it....my init and shutdown code hasn''t changed since I stol....er learnt it from NeHe''s openGL tutorials. It''s very simple stuff that worked fine for the last 2 weeks and now suddenly decided it doesn''t want to, despite not having been altered :/
It really is identical to NeHe''s tutorial except for one thing, which is a line to close a file. But that worked fine before no problems.
Perhaps it''s a memory leak/clear up issue? I have been doing a lot of extra object/linked list work in the program. I thought that in debug mode it catches any class destruction problems though....?
It really is identical to NeHe''s tutorial except for one thing, which is a line to close a file. But that worked fine before no problems.
Perhaps it''s a memory leak/clear up issue? I have been doing a lot of extra object/linked list work in the program. I thought that in debug mode it catches any class destruction problems though....?
It will be your extra object mangement stuff. Debug tells you where in the code the program was when it crashed not the cause of the crash. Step through all your object mangement code and check everything is well. If it isn''t fix it
Author
I already did a couple of times through the object management code because that was my first suspicion. I can''t find anything wrong with it, but maybe I''m just too thick too see it 
The crash occurs outside of my code though. It occurrs after the winMain returns. So what might cause the program to crash the windows code? Are there any common things that might cause this? According to debug, my program shuts down just fine, but when the windows shut-down code runs it bombs
The crash occurs outside of my code though. It occurrs after the winMain returns. So what might cause the program to crash the windows code? Are there any common things that might cause this? According to debug, my program shuts down just fine, but when the windows shut-down code runs it bombs
When i had my 3dfx voodoo 5 5500 all my opengl stuff (including nehe''s) would crash on exit in debug mode. In release mode, it worked fine. I''m guessing it was a problem with their drivers or something. Everything works fine with my gf3 tho. So in other words, if you have a 3dfx card that is probably your problem if the code is as clean as you claim it to be.
possible causes
- if you write beyond the limit of a pointer, say 30th index of an array of size 20..
- if you try to delete some dynamically allocated memory twice (not very sure about that in debug mode especially)..
- if you allocate memory with new but destroy with free()..
in short if you mess up with your arrays, those things happen.
hope that helps
- if you write beyond the limit of a pointer, say 30th index of an array of size 20..
- if you try to delete some dynamically allocated memory twice (not very sure about that in debug mode especially)..
- if you allocate memory with new but destroy with free()..
in short if you mess up with your arrays, those things happen.
hope that helps
Author
Well, I have a GF2. And I tried release mode just to be sure amd it still bombed
"if you write beyond the limit of a pointer, say 30th index of an array of size 20.."
Nope, no pointer arrays
"if you try to delete some dynamically allocated memory twice (not very sure about that in debug mode especially)"
Had a look to make sure, can''t see it if it is
"if you allocate memory with new but destroy with free()"
I never use free, and I only use new/delete.
Thanks for the advice, but it looks like I''m gonna have to keep searching.
"if you write beyond the limit of a pointer, say 30th index of an array of size 20.."
Nope, no pointer arrays
"if you try to delete some dynamically allocated memory twice (not very sure about that in debug mode especially)"
Had a look to make sure, can''t see it if it is
"if you allocate memory with new but destroy with free()"
I never use free, and I only use new/delete.
Thanks for the advice, but it looks like I''m gonna have to keep searching.
Well are you using linked lists? If you are post some code your''re using for them here and someone might be able to tell you what you''re doing wrong.
Actually post any memory related code.
Actually post any memory related code.
Author
Ok, here''s the code I use to manage the linked list....
Those are the two functions I use to add and remove objects from the list. The and is called from the constructor and remove from the destructor. At program close I use this:
Plyr is a global object created just before the main loop activates.
I''m pretty sure that''s clean code, I don''t see anything wrong with it, but maybe I''m just blind and/or stupid. And knowing my luck, I''ll spend the next 3 weeks going over every inch of my object management code only to find it''s not the objects causing the problem :/
void Actor::RemoveFromActorList(){ // remove this actor from the linked list if (FirstActor==NULL && LastActor==NULL) { log("what the f? both first actor and last actor are null!"); } if (FirstActor==this && LastActor==this) { FirstActor=NULL; LastActor=NULL; } else { if (next!=NULL && prev!=NULL) { next->prev=prev; prev->next=next; } else if (prev!=NULL) { LastActor=prev; LastActor->next=NULL; } else if (next!=NULL) { FirstActor=next; FirstActor->prev=NULL; } }}void Actor::AddToActorList(){ if (FirstActor==NULL) { FirstActor=this; LastActor=this; } else { Actor* A=FirstActor; do { if (A==LastActor) { LastActor->next=this; this->prev=LastActor; LastActor=this; A=this; } else { // check for height differences if (A!=NULL && A->zpos > this->zpos) { // found our slot A->next->prev=this; this->next=A->next; this->prev=A; A->next=this; } } A=A->next; } while (A!=NULL); }} Those are the two functions I use to add and remove objects from the list. The and is called from the constructor and remove from the destructor. At program close I use this:
Actor* A=FirstActor; Actor* A2; do { A2=A->next; delete A; A=A2; } while (A!=NULL); Plyr is a global object created just before the main loop activates.
I''m pretty sure that''s clean code, I don''t see anything wrong with it, but maybe I''m just blind and/or stupid. And knowing my luck, I''ll spend the next 3 weeks going over every inch of my object management code only to find it''s not the objects causing the problem :/
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
