GC BUG: Referenced object destroyed before released

[Graham St Jack]

On Mon, 17 Mar 2008 09:45:30 +0900, Bill Baxter wrote:

> Graham St Jack wrote:
> 
>> I guess the work-around (and maybe permanent) is to not reference any
>> garbage-collected objects in your destructors.
> 
> Err, that's more or less what the documentation says.
> 
> """
> When the garbage collector calls a destructor for an object of a class
> that has members that are references to garbage collected objects, those
> references are no longer valid. This means that destructors cannot
> reference sub objects.
> """
> -- http://www.digitalmars.com/d/1.0/class.html#destructors
> 
> Maybe it would be more precise to say "This means destructors cannot
> reference garbage collected objects".
> 
> --bb

Thanks for the clarification - it clears it up nicely for me.

Another question along these lines - I am having trouble with a multi-
threaded program (linux, gdc, phobos). It works fine until main() 
returns, and then I get a SIGUSR1 that causes the program to crash. Any 
ideas what might be happening?

My investigations so far show that SIGUSR1 and SIGUSR2 are used in 
thread.d as part of the implementation of pause() and resume(). I was 
under the impression that the thread that is interrupted to handle a 
signal is chosen at random, and therefore that it is a bad idea to try to 
use signals in a threaded program, so I am confused.

Also, the garbage collector seems to kill off all my threads without 
waiting for their run methods to return. I assume this means that the 
threads aren't being treated as root objects by the garbage collector.

Does all this mean that I have to explicitly take action so that the run 
methods will return, then wait() on them before returning from main()?