Bug 48723 - Native crash in ves_icall_System_Diagnostics_Process_GetProcess_internal
Summary: Native crash in ves_icall_System_Diagnostics_Process_GetProcess_internal
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer ()
Version: master
Hardware: PC Linux
: High critical
Target Milestone: ---
Assignee: Ludovic Henry
URL:
Depends on:
Blocks:
 
Reported: 2016-12-02 16:11 UTC by Mikhail Filippov
Modified: 2016-12-05 19:43 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
mono log (90.18 KB, text/plain)
2016-12-05 08:04 UTC, Mikhail Filippov
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Mikhail Filippov 2016-12-02 16:11:56 UTC
We have native crash:
Thread 49 (Thread 0x7fba9a89f700 (LWP 95)):
#0  0x00007fba9ea0bed9 in __libc_waitpid (pid=pid@entry=6817, stat_loc=stat_loc@entry=0x7fba9a89d50c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
#1  0x00000000004b3d9b in mono_handle_native_sigsegv (signal=<optimized out>, ctx=<optimized out>, info=<optimized out>) at mini-exceptions.c:2429
#2  <signal handler called>
#3  0x00007fba9e457c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#4  0x00007fba9e45b028 in __GI_abort () at abort.c:89
#5  0x0000000000654454 in mono_log_write_logfile (log_domain=<optimized out>, level=<optimized out>, hdr=<optimized out>, message=<optimized out>) at mono-log-common.c:137
#6  0x00000000006695fb in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x70fe88 "%s: handle %p has ref %d, it should be >= %d", args=0x7fba9a89e548) at goutput.c:115
#7  0x00000000006696b1 in monoeg_g_log (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x70fe88 "%s: handle %p has ref %d, it should be >= %d") at goutput.c:125
#8  0x00000000005c7ec0 in mono_w32handle_unref_core (handle=handle@entry=0x23, handle_data=handle_data@entry=0x2bdb360, minimum=minimum@entry=2) at w32handle.c:603
#9  0x00000000005c7fec in mono_w32handle_foreach (on_each=on_each@entry=0x5255f0 <get_process_foreach_callback>, user_data=user_data@entry=0x7fba9a89e6b0) at w32handle.c:561
#10 0x0000000000527569 in ves_icall_System_Diagnostics_Process_GetProcess_internal (pid=60) at w32process-unix.c:635
#11 0x0000000040551845 in ?? ()
#12 0x00007fba9e0176b0 in ?? ()
#13 0x00007fba9e0178c0 in ?? ()
#14 0x00007fba9e017640 in ?? ()
#15 0x00007fba9e017770 in ?? ()
#16 0x00007fba9b98c810 in ?? ()
#17 0x00007fba8c001dc0 in ?? ()
#18 0x00007fba9e0176b0 in ?? ()
#19 0x00007fba9a89e840 in ?? ()
#20 0x00007fba9a89e730 in ?? ()
#21 0x000000004055162c in ?? ()
#22 0x00007fba9e017770 in ?? ()
#23 0x00007fba9e017640 in ?? ()
#24 0x000000000000003c in ?? ()
#25 0x00007fba9a89e840 in ?? ()
#26 0x00007fba9a89e760 in ?? ()
#27 0x00007fba9bb5da77 in System_Threading_Thread_Sleep_int (millisecondsTimeout=3000) at /jonnyzzz/MonoRuntime/Unix/mono/mcs/class/referencesource/mscorlib/system/threading/thread.cs:741
#28 0x000000004054c440 in ?? ()
#29 0x0000000000000065 in ?? ()
#30 0x6e696f706b636568 in ?? ()
#31 0x00007fba9e0175f8 in ?? ()
#32 0x0000000000000000 in ?? ()
Comment 1 Miguel de Icaza [MSFT] 2016-12-03 02:40:51 UTC
We would want to look at a repro test case that shows this.

In the meantime, the code has definitely changed recently in commit 7eb2ea64 which introduced this unref that triggers the g_error.
Comment 2 Mikhail Filippov 2016-12-03 09:31:57 UTC
We have some crashes in our tests on CI. I try to make repro for it.
Comment 3 Ludovic Henry 2016-12-04 14:28:17 UTC
Hi Mikhail,

Could you please provide us the assertion message? And would you have a stacktrace of the other threads at the time of the crash?

Thank you!
Comment 4 Mikhail Filippov 2016-12-05 08:04:17 UTC
Created attachment 18768 [details]
mono log
Comment 5 Ludovic Henry 2016-12-05 19:31:08 UTC
This will be fixed with https://github.com/mono/mono/pull/4089
Comment 6 Mikhail Filippov 2016-12-05 19:43:57 UTC
@Ludovic Henry Great thanks! I'll check it.