Process.toNullEndedArray blocks indefinitely?

MichaelZ Joined: 02/02/10 Posts: 1

Posted: 04/07/10 08:59:07 Modified: 04/08/10 14:01:38 Hi, In my application, the following code never returned from the Process.execute: EDIT: I should add: this happened once in several thousand calls to Process.execute; it doesn't appear to be readily reproducible. Process process = new Process(true, command); scope (exit) { process.close(); } process.redirect(Redirect.All | Redirect.ErrorToOutput); process.execute; .... Looking into the (otherwise still running) processes with gdb I can see that the initiating thread of the "parent" Process is waiting on a read(): #0 0xffffe430 in __kernel_vsyscall () #1 0xb734abbb in read () from /lib/libpthread.so.0 #2 0x080a8587 in _D5tango2io6device6Device6Device4readMFAvZk () #3 0x080c2ad9 in _D5tango3sys7Process7Process7executeMFZC5tango3sys7Process7Process () ... (Presumably this is the pexec.source.input.read on line 1235 of Process.d). So far so standard - I gather it's waiting for some kind of response from the child. The child process looks unsatisfactory however; the exec has not yet happened, and the backtrace looks thusly: #0 0xffffe430 in __kernel_vsyscall () #1 0xb734a7b9 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0xb7345ce0 in _L_lock_286 () from /lib/libpthread.so.0 #3 0xb7345705 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x080c44f9 in _d_monitor_lock () #5 0x080990e0 in _d_monitorenter () #6 0x0809e96c in _D2rt2gc5basic3gcx2GC6mallocMFkkZPv () #7 0x0809e3e7 in gc_malloc () #8 0x0809cc6a in _d_newarrayT () #9 0x080c32d4 in _D5tango3sys7Process7Process16toNullEndedArrayFAAaZAPa () #10 0x080c2c62 in _D5tango3sys7Process7Process7executeMFZC5tango3sys7Process7Process () ... (Presumably this is the char*[] dest = new char*[src.length + 1]; on Line 1869 of Process.d) ... and it's been like this for about 2 hours. It looks to me like the child process is trying to acquire some memory management mutex which was locked by some (other) parent thread when the fork happened, and thus was copied (not shared) into the child in a locked state? Thus, when the thread of the parent unlocked the mutex again, the child never knew? I'm afraid I'm a little rusty on what exactly is copied and what is shared over a fork call, but can't see how a mutex could be sensibly shared. Am I on the wrong track completely, or is there really a problem here?

Author	Message
kris Joined: 03/27/04 Posts: 581	Posted: 05/22/10 19:56:00 Not sure what the issue might be, but it's certainly a bit odd that it's so sporadic