Bug 37900 - Crash starting Xamarin Studio
Summary: Crash starting Xamarin Studio
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-01-22 12:04 UTC by Alan McGovern
Modified: 2017-09-06 15:17 UTC (History)
7 users (show)

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:

Description Alan McGovern 2016-01-22 12:04:22 UTC
I got this crash starting Xamarin Studio with this version of mono:

Mono JIT compiler version 4.3.0 (mono-4.3.1-branch/2d945d7 Wed Jan 20 03:04:32 EST 2016)

INFO [2016-01-22 11:55:26Z]: Add-in loaded: MonoDevelop.Debugger.Soft
INFO [2016-01-22 11:55:26Z]: Add-in loaded: MonoDevelop.MonoAndroid
* Assertion: should not be reached at ./sgen-scan-object.h:101


  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) <IL 0x00027, 0xffffffff>
  at (wrapper alloc) object.AllocVector (intptr,intptr) <IL 0x00093, 0xffffffff>
  at System.IO.FileStream.InitBuffer (int,bool) [0x00094] in /private/tmp/source-mono-4.3.1/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/FileStream.cs:1120
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,bool,System.IO.FileOptions) [0x0030a] in /private/tmp/source-mono-4.3.1/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/FileStream.cs:284
  at System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) [0x00000] in /private/tmp/source-mono-4.3.1/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/FileStream.cs:97
  at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) <IL 0x00024, 0xffffffff>
  at Mono.Addins.Database.FileDatabase.FileLock (System.IO.FileAccess,int) [0x00035] in /Users/alan/Projects/monodevelop/main/external/mono-addins/Mono.Addins/Mono.Addins.Database/FileDatabase.cs:127
  at Mono.Addins.Database.FileDatabase.LockRead () [0x00000] in /Users/alan/Projects/monodevelop/main/external/mono-addins/Mono.Addins/Mono.Addins.Database/FileDatabase.cs:106
Comment 1 Ludovic Henry 2016-01-25 11:08:17 UTC
Looks like a bug in the runtime. Do you have a reproducible test case, or does it trigger reliably when starting XS with mono 2d945d7?
Comment 2 Alan McGovern 2016-01-25 14:17:27 UTC
It's random and seems to be pretty rare. This kind of crash in FileStream has shown in in the past though, so i don't think it's a recent regression.
Comment 3 Andi McClure 2016-02-08 18:50:15 UTC
If this happens, it always means sgen-scan-object.h scanned an object whose DESC_TYPE was DESC_TYPE_COMPLEX or DESC_TYPE_COMPLEX_ARR, and SCAN_OBJECT_NOVTABLE was not set. It looks(?) like FileStream did not do anything to prompt this except trigger a collection.
Comment 4 Andi McClure 2016-02-08 18:52:31 UTC
Err, correction: The issue will trigger when SCAN_OBJECT_NOVTABLE is *SET*.
Comment 8 Andi McClure 2016-02-10 23:33:32 UTC
Rodrigo saw this while running the appdomain-unload.exe test case

Thread 12 (process 28090):
#0  0x00007fff8a928902 in __wait4 ()
#1  0x000000010439a832 in mono_handle_native_sigsegv (signal=6, ctx=0x108802780, info=0x108802718) at mini-exceptions.c:2376
#2  0x0000000104470745 in sigabrt_signal_handler (_dummy=6, _info=0x108802718, context=0x108802780) at mini-posix.c:218
#3  <signal handler called>
#4  0x00007fff8a928286 in __pthread_kill ()
#5  0x00007fff943ad9f9 in pthread_kill ()
#6  0x00007fff975879b3 in abort ()
#7  0x0000000104697743 in monoeg_log_default_handler (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, message=0x7fd4aa50b140 "* Assertion: should not be reached at ./sgen-scan-object.h:101\n", unused_data=0x0) at goutput.c:233
#8  0x0000000104697652 in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x1046a9132 "* Assertion: should not be reached at %s:%d\n", args=0x108802ab0) at goutput.c:113
#9  0x0000000104697a54 in monoeg_assertion_message (format=0x1046a9132 "* Assertion: should not be reached at %s:%d\n") at goutput.c:133
#10 0x000000010462a25f in major_scan_object_no_evacuation (full_object=0x108274c30, desc=0, queue=0x10478c1f0) at sgen-scan-object.h:101
#11 0x00000001046243e4 in drain_gray_stack_no_evacuation (queue=0x10478c1f0) at sgen-marksweep-drain-gray-stack.h:289
#12 0x0000000104616936 in drain_gray_stack (queue=0x10478c1f0) at sgen-marksweep.c:1224
#13 0x00000001045fe567 in sgen_drain_gray_stack (ctx={ops = 0x10475dda8, queue = 0x10478c1f0}) at sgen-gc.c:544
#14 0x00000001046046cf in finish_gray_stack (generation=1, ctx={ops = 0x10475dda8, queue = 0x10478c1f0}) at sgen-gc.c:1073
#15 0x000000010460392e in major_finish_collection (reason=0x1046d230d "user request", old_next_pin_slot=44, forced=1) at sgen-gc.c:1917
#16 0x0000000104600467 in major_do_collection (reason=0x1046d230d "user request", forced=1) at sgen-gc.c:2042
#17 0x00000001045ff3c6 in sgen_perform_collection (requested_size=0, generation_to_collect=1, reason=0x1046d230d "user request", wait_to_finish=1) at sgen-gc.c:2259
#18 0x000000010460136c in sgen_gc_collect (generation=1) at sgen-gc.c:2684
#19 0x00000001045e8913 in mono_gc_collect (generation=1) at sgen-mono.c:2544
#20 0x0000000104587667 in unload_thread_main (arg=0x7fd4a850b2d0) at appdomain.c:2426
#21 0x000000010468ad0f in inner_start_thread (arg=0x7fff5b992120) at mono-threads-posix.c:92
#22 0x00007fff943ac05a in _pthread_body ()
#23 0x00007fff943abfd7 in _pthread_start ()
#24 0x00007fff943a93ed in thread_start ()
Comment 9 Andi McClure 2016-02-11 20:34:59 UTC
Possibly resolved by Rodrigo's new commit https://github.com/mono/mono/pull/2603, this should definitely address the various cases where appdomain-unload.exe is running, plausibly Alan's case also
Comment 10 Alexander Köplinger [MSFT] 2016-03-03 03:20:26 UTC
Another occurrence in the System.Web tests on Jenkins even after Rodrigo's fix: https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/3619/parsed_console/log_content.html#WARNING1

System.Web uses AppDomains a lot so it might still be related to that.

https://bugzilla.xamarin.com/show_bug.cgi?id=38941 has another report of the sgen-scan-object.h:101 assert on iOS.
Comment 11 Marek Safar 2017-09-06 13:59:27 UTC
@Alexander, is this still happening on Jenkins
Comment 12 Alexander Köplinger [MSFT] 2017-09-06 15:17:41 UTC
@Marek I ran a grep for the assertion on all Jenkins logs (see full list at https://gist.github.com/akoeplinger/978df05593094a20c0b00bd462705ef6).

Of those, the only occurrence that is newer than three months is this: https://jenkins.mono-project.com/job/test-mono-mainline-profilerstress/label=osx-amd64/45/

I'd say this is most probably fixed or extremely hard to trigger now so I'll close the bug.