Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

HUGE MEMORY LEAK pinpointed!

<< < (9/21) > >>

rickg22:
I'm really not sure, ParserThread is cbThreadedTask and not wxThread. So Delete() can't really belong to wxThread.

Biplab:

--- Quote from: rickg22 on June 22, 2007, 05:13:37 am ---I'm really not sure, ParserThread is cbThreadedTask and not wxThread. So Delete() can't really belong to wxThread.

--- End quote ---

Where is this exactly?

TDragon:
You guys are barking up the wrong tree if you're talking about that new[] leak.

I think the problem is that the destructor in LoaderBase, which is responsible for delete[]-ing data, isn't virtual. In sdk/filemanager.cpp:139,143, FileLoader* are pushed onto BackgroundThread queues. Then in include/backgroundthread.h:145-158 they're popped off as AbstractJob* and, if owned by the BackgroundThread, deleted. The LoaderBase destructor isn't in the object's vtable and we're delete-ing by way of an AbstractJob*, so ~LoaderBase() never happens and we have a missing delete[].

Edit:
Nope, I was wrong; a base class' virtual destructor forces derived classes' destructors to be virtual also.

Der Meister:
As there is a delete[] for this reported memory leak located in the destructor of LoaderBase I think there are only two possible problems:
- The destructor does not get called.
- FileLoader::operator() gets called more than once before the instance is destroyed. This way the operator() would just request more memory but not release the old one.

I don't know which of this two things happens but I hope for the second one as it should be easy to solve. I'm just running valgrind to check this.

rickg22:
Thomas, any ideas?

Navigation

[0] Message Index

[#] Next page

[*] Previous page