finalizer's not really finalizers? - causing segfaults

[Alan Knowles]

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