[D-runtime] druntime commit, revision 483

Sean Kelly sean at invisibleduck.org
Fri Jan 7 23:04:56 PST 2011

I think I've got it.  The collection that's running is probably when the runtime is terminating, so the spawned thread didn't start (and add itself to the thread list) until after thread_joinAll was called and things were shutting down.  Almost anything could have vanished by the time the receive operation is executed, and thus the weird behavior.  I'll have to go back to having Thread.start add the new thread to the list.  It's the way the code used to work until someone complained about a segfault that turned out to be a collection occurring when the new thread was still in the depths of the kernel startup code.  It's likely I'll have to add finer-grained state tracking, so a STARTING thread is suspended/resumed but not scanned, while a RUNNING thread is both suspended and scanned.  Sucks, but I don't see a way around it.

On Jan 7, 2011, at 10:24 PM, Sean Kelly wrote:

> This commit also fixes a race issue between newly created threads and the GC.  I have one remaining issue to sort out, but not being able to debug on OSX is somewhat of a problem.  I'll look into it more on Linux this weekend, with luck.  The issue is that when I run the following app, sometimes I get a bus error, it hangs, I get a segfault, or there's no output.  It's something within std.concurrency, but it's hard to say what without a debugger.  Here's the code:
> import std.concurrency;
> import core.stdc.stdio;
> void thr() {
>  scope(failure) printf( "failure\n" );
>  receive(
>    (OwnerTerminated)
>    {
>        printf( "received\n" );
>    }
> );
> printf( "done\n" );
> }
> void main() {
> spawn(&thr);
> }
> And here's a backtrace:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000074
> [Switching to process 4169]
> 0x000025af in D3std11concurrency10MessageBox48__T3getTDFC3std11concurrency15OwnerTerminatedZvZ3getMFDFC3std11concurrency15OwnerTerminatedZvZb13onLinkDeadMsgMFKS3std11concurrency7MessageZb ()
> (gdb) bt
> #0  0x000025af in D3std11concurrency10MessageBox48__T3getTDFC3std11concurrency15OwnerTerminatedZvZ3getMFDFC3std11concurrency15OwnerTerminatedZvZb13onLinkDeadMsgMFKS3std11concurrency7MessageZb ()
> #1  0x0000278b in D3std11concurrency10MessageBox48__T3getTDFC3std11concurrency15OwnerTerminatedZvZ3getMFDFC3std11concurrency15OwnerTerminatedZvZb12onControlMsgMFKS3std11concurrency7MessageZb ()
> #2  0x00002800 in D3std11concurrency10MessageBox48__T3getTDFC3std11concurrency15OwnerTerminatedZvZ3getMFDFC3std11concurrency15OwnerTerminatedZvZb4scanMFKS3std11concurrency36__T4ListTS3std11concurrency7MessageZ4ListZb ()
> #3  0x0000248d in D3std11concurrency10MessageBox48__T3getTDFC3std11concurrency15OwnerTerminatedZvZ3getMFDFC3std11concurrency15OwnerTerminatedZvZb ()
> #4  0x00002346 in D3std11concurrency52__T7receiveTDFC3std11concurrency15OwnerTerminatedZvZ7receiveFDFC3std11concurrency15OwnerTerminatedZvZv ()
> #5  0x0000229b in D3xxx3thrFZv ()
> #6  0x00004138 in D3std11concurrency11__T6_spawnZ6_spawnFbPFZvZS3std11concurrency3Tid4execMFZv ()
> #7  0x0000c5a6 in D4core6thread6Thread3runMFZv ()
> #8  0x0000bb20 in thread_entryPoint ()
> #9  0x960277fd in _pthread_start ()
> #10 0x96027682 in thread_start ()
> Seems like I'm passing a NULL into the ctor for Message, but I don't see where.  That this appears to be timing related is even weirder.  Hopefully a real debugger will turn something up.
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

More information about the D-runtime mailing list