Bug 679936

Summary: Process.Start leaves child processes around unless WaitForExit() is called
Product: [Mono] Mono: Runtime Reporter: Thomas Philpot <tom.philpot>
Component: io-layerAssignee: Paolo Molaro <lupus>
Status: RESOLVED DUPLICATE QA Contact: Mono Bugs <mono-bugs>
Severity: Normal    
Priority: P5 - None    
Version: 2.10.x   
Target Milestone: ---   
Hardware: x86   
OS: Mac OS X 10.6   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: ProcessTest.cs file

Description Thomas Philpot 2011-03-15 21:12:31 UTC
Created attachment 419528 [details]
ProcessTest.cs file

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0

Running the attached program will eventually crash on Mac because the limit for kern.maxprocperuid will be reached. The problem appears to be that Process.Dispose() doesn't cleanup everything that it should and processes are still hanging around.



Reproducible: Always

Steps to Reproduce:
1. Compile the attached program.
2. Open two Terminals
3. Run the attached program in one terminal and in the other terminal, run "ps -x" while the program is running. You should see lots of "echo" processes hanging around.
Actual Results:  
Eventually the call to fork() will fail and you'll get a Win32Exception.

Expected Results:  
Process.Dispose() should not leave the processes hanging around.
Comment 1 Rolf Kvinge 2011-03-15 21:58:23 UTC
This is a duplicate of #668867, which was unfortunately resolved as WONTFIX.

*** This bug has been marked as a duplicate of bug 668867 ***
Comment 2 Thomas Philpot 2011-03-15 23:42:12 UTC
Strangely, with my build of Mono 2.10.1 in /opt/mono-2.10 the following doesn't fix the problem

MONO_ENABLE_SHM=1 /opt/mono-2.10/bin/mono ProcessTest.exe

The zombie processes still hang around.  Am I doing something wrong?
Comment 3 Rolf Kvinge 2011-03-15 23:46:49 UTC
IIRC mono 2.10 was built without support for shared handles.
Comment 4 Gonzalo Paniagua Javier 2011-03-16 05:53:41 UTC
Bug #668867 is now properly fixed.