Thanks for looking into this.  I had been ignoring this because I thought it was related to 6014 (<a href="http://d.puremagic.com/issues/show_bug.cgi?id=6014">http://d.puremagic.com/issues/show_bug.cgi?id=6014</a>).  I'm a little bit confused about what the root cause is.  How can memory that the daemon thread still has access to be getting freed?  In terms of root cause, is this a bug in std.parallelism or druntime?<br>
<br><div class="gmail_quote">On Tue, Sep 13, 2011 at 2:59 PM, Martin Nowak <span dir="ltr"><<a href="mailto:dawg@dawgfoto.de">dawg@dawgfoto.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've had a look the core dumps from the sometimes failing std.parallelism test.<br>
The issue is one of having daemon threads running while the GC is unmapping memory.<br>
Usually this goes unnoticed because the parallelism threads wait in a work queue condition.<br>
Sometimes a daemon thread is awakening from it's GC suspend handler after memory was already<br>
freed. This issue is already mentioned in a comment at gc_term.<br>
<br>
<br>
Thread  obj = Thread.getThis();<br>
<br>
...<br>
suspend<br>
...<br>
<br>
if( obj && !obj.m_lock ) // <- segfault<br>
<br>
<br>
I think we should bluntly kill daemon threads after thread_joinAll.<br>
<br>
martin<br>
______________________________<u></u>_________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/phobos</a><br>
</blockquote></div><br>