On Mon, 12 Nov 2007, Brendon Costa wrote:
I can see the call of the destructor method working correctly in all cases. As you said it is just a virtual function call. However i was wondering if the memory de-allocation is performed by the child or the caller.
In general, memory management done by the caller. This lets a single constructor/destructor work for both stack memory (local variables) and heap memory (~malloc/free).
If the caller, then it is possible that the memory is allocated in the plugin and freed in the application. I am unsure if this could be a problem or not? I think it could be a problem depending on the implementation of the memory allocation routines for new/delete.
As long as you aren't doing anything fancy with "operator new()" and "operator delete()", this shouldn't be a problem.
If for example the memory allocation/deallocation was implemented using a global static list of currently owned memory blocks or something similar, which exists once in the plugin and once in the application. Then we can have a problem as the plugin list will contain the reference for the allocated memory, but the application list does not and is asked to free the memory. But I dont know if this would ever happen?
The spot where I could see this happening is when objects are created on one side of the dlopen and deleted on another... and "operator new/delete" were customized as you mention. Then delete could try to put things back in the wrong place.
Here's a relevant post from the GCC list; it mentions how to work around some dlopen difficulties (including RTTI, exceptions, custom new/delete).
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00248.html - Daniel _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
