🔒 Locked

Wierd error : debug error !

Started by Daivuk Jan 25, 2006 at 11:42 AM 6 replies 1k views

Original Post

Jan 25, 2006 at 11:42 AM

Hi, I cant get out with this error.... When running my app, I close it, then I get this error : Debug Error! Program: Cours2.exe DAMAGE: after Normal block (#358) at 0x00E210D0. (Press Retry to debug the application) Here is the context where it crash : -> _free_dbg_lk(void *, int) _free_dbg(void *, int) operator delete(void *) CEmiter::'scalar deleting destructor'(unsigned int) I debug it, it crash when exiting my ~CEmiter destructor. The object exist. Every of his objects deleted succesfully also. It crash when exiting the destructor :S I've never see that before. I searched on google, but juste found problems with specific platform or applications trying to compile. Me its juste a simple C++ OOP particle system for school. I have a std::vector of CEmiter* : std::vector emiters; I'm deleting them like this :


for (int i=0;i<emiters.size();i++){
	CEmiter * emiter = emiters.at(i);
	delete emiter;  // Crash here
}
emiters.clear();

It crash to the first one. I always delete my vectors like this :S I wonder if someone already got similar error and can point me out When it supposed to append. Thanks !!

Skeleton_V@T

Jan 25, 2006 at 12:20 PM

The reason for the crash is not so obscure: You manually deleted all the object while the vector object didn't noticed about the changes. When you call std::vector::erase () member function, they (the contained objects) were deleted again, results in an undefined behavior. You may fix this problem in the following ways:

Set the pointer to NULL after deleting:

for (int i=0;i<emiters.size();i++){	CEmiter * emiter = emiters.at(i);	delete emiter;  // Crash here        emiters = NULL ; //New}emiters.clear();

Deleting a NULL pointer is a no-op, so it is safe to delete it twice.

I'm just joking[wink], the safest method is to remove all the for loop above and rely to the vector to delete its objects. If you want to remove the object one by one, you may call erase () or pop_back () methods, for details you may look at MSDN.

Daivuk

Author

Daivuk

Jan 25, 2006 at 12:36 PM

Ya but, erase() dont delete my pointers for me!??!
No, sure not.
Thats why I have to pass the vector and first delete my objets.
Then clear(), just erase the "pointers", not delete them.
Erase jsut remove the objet (that is a pointer)
Vector dont perform a "delete" on it.
Do I'm wrong?

Daivuk

Author

Daivuk

Jan 25, 2006 at 12:42 PM

Ok, Ive just tested it, and i'm right ;)

My vector just contain pointers, it dont care about to "delete" them.
Because you can create pointer of float is you want, not necessary float*.
So you have to delete hem all like I'm doing.
clear() just erase all the pointers, and dont care about to delete it.

So, putting emiters = NULL didnt solve my problem.
And its not a vector problem, the error occur BEFORE that.
When deleting a single object.

Thanks anyway to reply :)

Daivuk

Author

Daivuk

Jan 25, 2006 at 12:55 PM

Ho, and hey.
I also tested just doing this :

CEmiter * emiter = new CEmiter();
delete emiter; // Crash here

So this is not a thread about vector problems ;)

Thanks

Erzengeldeslichtes

Jan 25, 2006 at 1:09 PM

In that case we'll need to know a bit more about the emitter class. It's obviously thrashing its memory in either its constructor or destructor. Probably writing to someplace before or after its memory and the debug code is noticing it while it tries to clean it up.

Daivuk

Author

Daivuk

Jan 25, 2006 at 1:28 PM

Thanks for reply.

Ok guys, I finally found it !!!!!
My CEmiter contain a matrix, and this matrix contain a member :
m[8] :$

it should be m[9] hehe
My bad.
But its wierd, because I have used my matrix class a lot before hehe.

Erzengeldeslichtes

Jan 25, 2006 at 1:38 PM

So you're saying you wrote to the 9th index on an 8 index array?

It may appear to work sometimes when your class isn't packed enough. For example, doing:

struct _test{    char MyArray[3];} test;test.MyArray[3] = 0;

will probably work because the compiler will want to pad it out to sizeof(test) == 4, but the extra byte is just padding and wouldn't be accessed, except you try to access the non-existant 4th index. The problem asserts itself, though, when you then do:

struct{    char i;    _test MyTest;} Test2;Test2.MyTest.MyArray[3] = 0;

Now the compiler wants to leave it at sizeof(Test2) == 4, and so accessing the fourth index will access data not owned by the object (while without the preceding char it would set aside the extra byte as padding)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.