[Mono-bugs] [Bug 557921] New: System.Diagnostics.Process: error creating process handle
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Mon Nov 23 19:23:57 EST 2009
http://bugzilla.novell.com/show_bug.cgi?id=557921
http://bugzilla.novell.com/show_bug.cgi?id=557921#c0
Summary: System.Diagnostics.Process: error creating process
handle
Classification: Mono
Product: Mono: Runtime
Version: 2.4.x
Platform: x86
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: P5 - None
Component: io-layer
AssignedTo: lupus at novell.com
ReportedBy: brian at sooloos.com
QAContact: mono-bugs at lists.ximian.com
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
It appears that System.Diagnostics.Process is leaking "process handles". After
kicking off approximately 500 processes (and disposing each Process object
immediately after calling Start()), I start getting warning trace each time I
attempt to start the process. No exception is thrown yet the process is not
started.
Since this bug was encountered in context of a production system, I've included
a tiny test program below that reproduces the bug reliably and quickly on mono
2.4.2.3.
The test program creates a lot of processes very quickly. The production system
creates processes at a significantly slower rate: less than one per minute. As
a result, the production system doesn't fail until it's been running for many
hours. Both exhibit the same failure, however. It doesn't seem that the rate of
process creation is at fault here.
If I kill the program and immediately run it again, then mono segv's (stack
dump is included below). rm'ing ~/.wapi seems to repair the leak temporarily,
as does waiting a few minutes before starting the program again runs.
If I add a call to p.WaitForExit() directly after the call to p.Start() then
all failures go away and it runs for hundreds of thousands of iterations
without issue.
The .net api as published by microsoft does not require that WaitForExit is
called, nor does it fail to execute this code. The call to Dispose() on the
process object should be sufficient to release all mono-spefic resources
associated with the process.
I see that there was a bug for this years ago that was closed a long time ago
(https://bugzilla.novell.com/show_bug.cgi?id=79040). Other assorted googling
seems to suggest that there is uncertainty of whether the "fix" for this past
bug actually addressed the root cause.
Also of note:
- this program seems to leak memory as it continues to iteratively print the
WARNING message. After letting it run for five minutes it has ~100mb resident,
compared to ~15mb at startup.
- in the midst of printing the WARNING message, after a few minutes, it will
start to successfully create 'ls' processes once again, later reverting to the
failure behavior.
Reproducible: Always
Steps to Reproduce:
Compile and run this code:
using System;
using System.Diagnostics;
public class Test
{
public static void Main(string[] args)
{
int count = 0;
while (true) {
Console.WriteLine("Starting Process #{0}", (++count));
using (Process p = new Process()) {
p.StartInfo.FileName = "/bin/ls";
p.StartInfo.UseShellExecute = false;
p.StartInfo.CreateNoWindow = true;
p.StartInfo.WorkingDirectory = "/";
p.Start();
}
count++;
}
}
}
Actual Results:
Program runs for about 500 iterations of the main loop, each time printing the
directory listing of "/". After approximately 500 iterations, it start printing
the following once per call to p.Start():
** (testprocess.exe:10013): WARNING **: CreateProcess: error creating process
handle
If I kill the program and run it again immediately, mono segfaults with the
following output:
brian at zuu test $ mono testprocess.exe
** (testprocess.exe:10533): WARNING **: process_set_current: error creating
process handle
Starting Process #1
** (testprocess.exe:10533): WARNING **: CreateProcess: error creating process
handle
Stacktrace:
at (wrapper managed-to-native)
System.Diagnostics.Process.CreateProcess_internal
(System.Diagnostics.ProcessStartInfo,intptr,intptr,intptr,System.Diagnostics.Process/ProcInfo&)
<0x00004>
at (wrapper managed-to-native)
System.Diagnostics.Process.CreateProcess_internal
(System.Diagnostics.ProcessStartInfo,intptr,intptr,intptr,System.Diagnostics.Process/ProcInfo&)
<0xffffffff>
at System.Diagnostics.Process.Start_noshell
(System.Diagnostics.ProcessStartInfo,System.Diagnostics.Process) <0x00847>
at System.Diagnostics.Process.Start_common
(System.Diagnostics.ProcessStartInfo,System.Diagnostics.Process) <0x000d9>
at System.Diagnostics.Process.Start () <0x00042>
at (wrapper remoting-invoke-with-check) System.Diagnostics.Process.Start ()
<0xffffffff>
at Test.Main (string[]) <0x00118>
at (wrapper runtime-invoke) Test.runtime_invoke_void_object
(object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono [0x80cc044]
mono [0x80f671b]
[0xb7f5540c]
mono [0x81b16b6]
mono [0x81e45d8]
[0xb78ae229]
[0xb78ad238]
[0xb78ac87a]
[0xb78ac773]
[0xb78ac6fc]
[0xb789f3a1]
[0xb789f203]
mono(mono_runtime_exec_main+0xe5) [0x8185625]
mono(mono_runtime_run_main+0x16b) [0x8185dcb]
mono(mono_main+0x190a) [0x80b38fa]
mono [0x805afb1]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7cf6775]
mono [0x805aee1]
Debug info from gdb:
[Thread debugging using libthread_db enabled]
[New Thread 0xb7cac6f0 (LWP 10533)]
[New Thread 0xb74e1b90 (LWP 10535)]
[New Thread 0xb7505b90 (LWP 10534)]
0xb7f55424 in __kernel_vsyscall ()
3 Thread 0xb7505b90 (LWP 10534) 0xb7f55424 in __kernel_vsyscall ()
2 Thread 0xb74e1b90 (LWP 10535) 0xb7f55424 in __kernel_vsyscall ()
1 Thread 0xb7cac6f0 (LWP 10533) 0xb7f55424 in __kernel_vsyscall ()
Thread 3 (Thread 0xb7505b90 (LWP 10534)):
#0 0xb7f55424 in __kernel_vsyscall ()
#1 0xb7e768f6 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x081bbb48 in collection_thread (unused=0x0) at collection.c:34
#3 0xb7e6f4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7dc449e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 2 (Thread 0xb74e1b90 (LWP 10535)):
#0 0xb7f55424 in __kernel_vsyscall ()
#1 0xb7e753f5 in sem_wait@@GLIBC_2.1 () from
/lib/tls/i686/cmov/libpthread.so.0
#2 0x08162309 in finalizer_thread (unused=0x0) at gc.c:1058
#3 0x08190e38 in start_wrapper (data=0x894f040) at threads.c:623
#4 0x081b5a26 in thread_start_routine (args=0x895161c) at threads.c:286
#5 0x081d0218 in GC_start_routine (arg=0x35f20) at pthread_support.c:1382
#6 0xb7e6f4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb7dc449e in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (Thread 0xb7cac6f0 (LWP 10533)):
#0 0xb7f55424 in __kernel_vsyscall ()
#1 0xb7dc0a87 in syscall () from /lib/tls/i686/cmov/libc.so.6
#2 0x080cc16d in mono_handle_native_sigsegv (signal=11, ctx=0xb7b65d0c) at
mini-exceptions.c:1526
#3 0x080f671b in mono_arch_handle_altstack_exception (sigctx=0xb7b65d0c,
fault_addr=0x3b80, stack_ovf=0)
at exceptions-x86.c:881
#4 <signal handler called>
#5 _wapi_handle_unref (handle=0x3dd70) at handles.c:1048
#6 0x081b16b6 in CloseHandle (handle=0x70) at handles.c:1327
#7 0x081e45d8 in ves_icall_System_Diagnostics_Process_CreateProcess_internal
(proc_start_info=0x3dd70,
stdin_handle=0x0, stdout_handle=0x1, stderr_handle=0x2,
process_info=0xbfb733fc) at process.c:782
#8 0xb78ae229 in ?? ()
#9 0xb78ad238 in ?? ()
#10 0xb78ac87a in ?? ()
#11 0xb78ac773 in ?? ()
#12 0xb78ac6fc in ?? ()
#13 0xb789f3a1 in ?? ()
#14 0xb789f203 in ?? ()
#15 0x08185625 in mono_runtime_exec_main (method=0x76f50, args=0x3be70,
exc=0x0) at object.c:3309
#16 0x08185dcb in mono_runtime_run_main (method=0x8937264, argc=0,
argv=0xbfb73808, exc=0x0) at object.c:3089
#17 0x080b38fa in mono_main (argc=2, argv=0xbfb73804) at driver.c:972
#18 0x0805afb1 in main (argc=144297728, argv=0x0) at main.c:34
#0 0xb7f55424 in __kernel_vsyscall ()
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted
If I rm -Rf ~/.wapi or wait a few minutes between runs, then I can run it again
and get 500 more successful p.Start() calls before the failures begin.
Expected Results:
Program runs indefinitely, printing the directory listing of "/" over and over
again.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the mono-bugs
mailing list