• Alan Knowles (10/10) Sep 07 2008 One of the segfaults I was getting was in
• Sean Kelly (3/14) Sep 08 2008 It's more likely that you have a dangling reference or something like th...
• Alan Knowles (10/28) Sep 09 2008 I think i nailed it down to one of the destructors calling
• Sean Kelly (5/12) Sep 10 2008 Mutexes in D are recursive. I don't think this should change, as it

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

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

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

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