It's an issue with the runtime shutdown.
It ultimately unmaps all memory.
Something simpler like this will always segfault for me.
import std.parallelism, std.stdio;
void printChar(dchar c) {
write(c);
}
void main() {
foreach(c; "hello world\n")
taskPool.put(task!printChar(c));
}
I can't think of any benefit in letting daemon threads continue up to
program termination.
On Tue, 13 Sep 2011 21:37:26 +0200, David Simcha <[email protected]> wrote:
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).
Which is another bug/oversight in the runtime shutdown.
I've stumbled over this when sketching out the allocators.
Will clarify this with a reduced test case.
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
