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

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

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

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