[Mono-dev] Process.Start and WaitForExit on MacOS X

[Tom Philpot]

Apparently, the bug I filed was marked as a duplicate of this WONTFIX bug:
https://bugzilla.novell.com/show_bug.cgi?id=668867

According to the resolution of that bug, I just need to enable shared
handles. Unless I'm doing something wrong, enabling shared handles should
be as simple as "MONO_ENABLE_SHM=1 mono ProcessTest.exe", right?

That doesn't seem to fix the issue.

We're finding that running CruiseControl.Net under Mono creates zombies
because the processes aren't waited for, and this happened even in 2.6,
where IIRC, shared handles were enabled by default.

Thanks,
Tom

On 3/15/11 2:15 PM, "Tom Philpot" <tom.philpot at logos.com> wrote:

>Submitted bug with a reproducible test case:
>https://bugzilla.novell.com/show_bug.cgi?id=679936
>
>On 3/15/11 12:26 PM, "Jonathan Pryor" <jonpryor at vt.edu> wrote:
>
>>On Mar 15, 2011, at 2:57 PM, Tom Philpot wrote:
>>> I've discovered that Process.Start(ProcessStartInfo info) leaves child
>>>processes hanging around until the parent process dies, unless you call
>>>WaitForExit() on the child process.
>>...
>>> Is this a bug or by design?
>>
>>The problem is the Process.ExitCode property. There's no way to retrieve
>>this value except through the waitpid(2) (and related) system calls, so
>>the process can't be fully disposed just in case the ExitCode property
>>will be accessed.
>>
>>That said, once the instance has been disposed, it shouldn't be necessary
>>to keep anything open, and the child handles should be closed. Given that
>>you _are_ using a `using` block, and thus disposing of the instance, it
>>seems that this is likely a bug and that Process.Dispose() isn't fully
>>closing all resources as it should.
>>
>>(For that matter, the Process finalizer should also be disposing of
>>unmanaged resources, and it looks like that isn't the case either).
>>
>>Could you please file a bug?
>>
>>Thanks,
>> - Jon
>>
>