www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - finalizer's not really finalizers? - causing segfaults

reply Alan Knowles <alan akbkhome.com> writes:
One of the segfaults I was getting was in
_d_finalizer() - c.destructor was pointing to an invalid address..

What I'm suspecting happens is that the compiler thinks that casting the 
pointer to a (ClassInfo **) appears to be valid, but is not actually.. 
and then c.destructor points to an invalid address, causing a segfault.

by removing the calls in the GC to the finalizer - I think this bug gets 
solved (however obviously ~this() probably doesnt work any more..)

Is this a feasible situation????

Regards
Alan
Sep 07 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
Alan Knowles wrote:
 One of the segfaults I was getting was in
 _d_finalizer() - c.destructor was pointing to an invalid address..
 
 What I'm suspecting happens is that the compiler thinks that casting the 
 pointer to a (ClassInfo **) appears to be valid, but is not actually.. 
 and then c.destructor points to an invalid address, causing a segfault.
 
 by removing the calls in the GC to the finalizer - I think this bug gets 
 solved (however obviously ~this() probably doesnt work any more..)
 
 Is this a feasible situation????

It's more likely that you have a dangling reference or something like that. Sean
Sep 08 2008
parent reply Alan Knowles <alan akbkhome.com> writes:
I think i nailed it down to one of the destructors calling 
std.gc.genCollect()

I'm wondering though why that did not cause a deadlock situation

genCollect() -> calls the destructor -> destructor calls genCollect() or 
any other gc related stuff - it's supposed to be caught by the gcLock??

It looks like an inherent risk of using destructors -  I could not see 
any code that tries to prevent memory operations from destructors..???

Regards
Alan





Sean Kelly wrote:
 Alan Knowles wrote:
 One of the segfaults I was getting was in
 _d_finalizer() - c.destructor was pointing to an invalid address..

 What I'm suspecting happens is that the compiler thinks that casting 
 the pointer to a (ClassInfo **) appears to be valid, but is not 
 actually.. and then c.destructor points to an invalid address, causing 
 a segfault.

 by removing the calls in the GC to the finalizer - I think this bug 
 gets solved (however obviously ~this() probably doesnt work any more..)

 Is this a feasible situation????

It's more likely that you have a dangling reference or something like that. Sean

Sep 09 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Alan Knowles wrote:
 I think i nailed it down to one of the destructors calling 
 std.gc.genCollect()
 
 I'm wondering though why that did not cause a deadlock situation
 
 genCollect() -> calls the destructor -> destructor calls genCollect() or 
 any other gc related stuff - it's supposed to be caught by the gcLock??

Mutexes in D are recursive. I don't think this should change, as it allows a dtor to allocate memory, for example, which can be useful in logging and so on. Sean
Sep 10 2008