Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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 ?? ()
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.
We have some crashes in our tests on CI. I try to make repro for it.
Could you please provide us the assertion message? And would you have a stacktrace of the other threads at the time of the crash?
Created attachment 18768 [details]
This will be fixed with https://github.com/mono/mono/pull/4089
@Ludovic Henry Great thanks! I'll check it.