Thanks for looking into this. I had been ignoring this because I thought it was related to 6014 (http://d.puremagic.com/issues/show_bug.cgi?id=6014). 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?
On Tue, Sep 13, 2011 at 2:59 PM, Martin Nowak <[email protected]> wrote: > I've had a look the core dumps from the sometimes failing std.parallelism > test. > The issue is one of having daemon threads running while the GC is unmapping > memory. > Usually this goes unnoticed because the parallelism threads wait in a work > queue condition. > Sometimes a daemon thread is awakening from it's GC suspend handler after > memory was already > freed. This issue is already mentioned in a comment at gc_term. > > > Thread obj = Thread.getThis(); > > ... > suspend > ... > > if( obj && !obj.m_lock ) // <- segfault > > > I think we should bluntly kill daemon threads after thread_joinAll. > > martin > ______________________________**_________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/**mailman/listinfo/phobos<http://lists.puremagic.com/mailman/listinfo/phobos> >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
