Bug 4194 - finally guard reliably crashes on OSX
Summary: finally guard reliably crashes on OSX
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-04-02 15:43 UTC by Rodrigo Kumpera
Modified: 2014-01-17 18:13 UTC (History)
2 users (show)

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

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 Rodrigo Kumpera 2012-04-02 15:43:42 UTC
To reproduce run:  ../mini/mono --regression finally_guard.exe
It reliably crashes at the end.
Comment 1 Rodrigo Kumpera 2014-01-17 18:10:46 UTC
Fixed this one:

Thread 3 (process 18649):
#0  0x92e0509a in __wait4 ()
#1  0x934c398a in waitpid$UNIX2003 ()
#2  0x00223e23 in mono_handle_native_sigsegv (signal=11, ctx=0x179bfe0) at mini-exceptions.c:2299
#3  0x002d04e2 in mono_arch_handle_altstack_exception (sigctx=0x179bfe0, fault_addr=0x8, stack_ovf=0) at exceptions-x86.c:1165
#4  0x0010d465 in mono_sigsegv_signal_handler (_dummy=10, info=0x179bfa0, context=0x179bfe0) at mini.c:6784
#5  <signal handler called>
#6  0x003b1175 in mono_cq_dequeue (cq=0x0, result=0xb0224e48) at mono-cq.c:241
#7  0x003e03e9 in dequeue_or_steal (tp=0x61da18, data=0xb0224e48, local_wsq=0x78624020) at threadpool.c:1305
#8  0x003dd05a in async_invoke_thread (data=0x0) at threadpool.c:1578
#9  0x003dbc4c in start_wrapper_internal (data=0x7920ba10) at threads.c:611
#10 0x003db842 in start_wrapper (data=0x7920ba10) at threads.c:656
#11 0x005172d5 in inner_start_thread (arg=0xbff070d8) at mono-threads-posix.c:97
#12 0x934395b7 in _pthread_start ()
#13 0x93423dce in thread_start ()

Thread 2 (process 18649):
#0  0x92e04c72 in __semwait_signal ()
#1  0x934c3a49 in nanosleep$UNIX2003 ()
#2  0x004f888f in SleepEx (ms=500, alertable=1) at wthreads.c:624
#3  0x003e0e7d in monitor_thread (unused=0x0) at threadpool.c:779
#4  0x003dbc4c in start_wrapper_internal (data=0x7920ba10) at threads.c:611
#5  0x003db842 in start_wrapper (data=0x7920ba10) at threads.c:656
#6  0x005172d5 in inner_start_thread (arg=0xbff07138) at mono-threads-posix.c:97
#7  0x934395b7 in _pthread_start ()
#8  0x93423dce in thread_start ()

Thread 1 (process 18649):
#0  0x92e04c72 in __semwait_signal ()
#1  0x934c3a49 in nanosleep$UNIX2003 ()
#2  0x0052e7ea in monoeg_g_usleep (microseconds=730) at gdate-unix.c:53
#3  0x004c9cf7 in restart_threads_until_none_in_managed_allocator () at sgen-stw.c:153
#4  0x004c9805 in sgen_stop_world (generation=0) at sgen-stw.c:216
#5  0x0046483a in mono_gc_clear_domain (domain=0x7860ff60) at sgen-gc.c:1055
#6  0x00411697 in mono_domain_free (domain=0x7860ff60, force=1) at domain.c:2003
#7  0x001113c2 in mini_cleanup (domain=0x7860ff60) at mini.c:7651
#8  0x001dce6d in mono_main (argc=3, argv=0xbff07c34) at driver.c:1924
#9  0x000fa678 in mono_main_with_options (argc=3, argv=0xbff07c34) at main.c:91
#10 0x000fa270 in main (argc=3, argv=0xbff07c34) at main.c:122
Comment 2 Rodrigo Kumpera 2014-01-17 18:13:16 UTC
Looks like 20 months of fixing in the shutdown code won this one for us! Awesome!