Bug 3424 - MonoDevelop crashes constantly under Mono 2.10.9 on MacOS
Summary: MonoDevelop crashes constantly under Mono 2.10.9 on MacOS
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: Trunk
Hardware: PC Mac OS
: Highest critical
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-02-13 11:43 UTC by Alan McGovern
Modified: 2012-02-14 23:25 UTC (History)
5 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 Developer Community or GitHub 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 Alan McGovern 2012-02-13 11:43:51 UTC
1) Do something which causes an exception to be thrown.
2) Expand the details section of the exception dialog
3) Try to scroll the window

Result:
Crashes

Screencast:
http://screencast.com/t/8Lle3gjAd1eC
Comment 1 Mikayla Hutchinson [MSFT] 2012-02-13 11:44:49 UTC
Trace?
Comment 2 Alan McGovern 2012-02-13 11:46:05 UTC
Thread 1 (process 26971):
#0  0x9c14ac22 in mach_msg_trap ()
#1  0x9c14a1f6 in mach_msg ()
#2  0x90451c7a in __CFRunLoopServiceMachPort ()
#3  0x9045ada4 in __CFRunLoopRun ()
#4  0x9045a47c in CFRunLoopRunSpecific ()
#5  0x9045a328 in CFRunLoopRunInMode ()
#6  0x9674c17f in RunCurrentEventLoopInMode ()
#7  0x967534e7 in ReceiveNextEventCommon ()
#8  0x96753356 in BlockUntilNextEventMatchingListInMode ()
#9  0x04b64a9c in _DPSNextEvent ()
#10 0x04b64306 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#11 0x04e38b17 in -[NSApplication _realDoModalLoop:peek:] ()
#12 0x04e33c1d in -[NSApplication _doModalLoop:peek:] ()
#13 0x04e386a4 in -[NSApplication runModalForWindow:] ()
#14 0x04e28ab3 in -[NSAlert runModal] ()
#15 0x11df4928 in ?? ()
#16 0x11df48a0 in ?? ()
#17 0x11debfec in ?? ()
#18 0x11dea359 in ?? ()
#19 0x11dea08a in ?? ()
#20 0x11dea24d in ?? ()
#21 0x0000d612 in mono_jit_runtime_invoke (method=0xeb31eac, obj=0x9a821b0, params=0xbfffdb30, exc=0x0) at mini.c:5791
#22 0x0016d28e in mono_runtime_invoke (method=0xeb31eac, obj=0x9a821b0, params=0xbfffdb30, exc=0x0) at object.c:2755
#23 0x00173a48 in mono_runtime_invoke_array (method=0x10004005, obj=0x10004005, params=0x11303578, exc=0x0) at object.c:4142
#24 0x0011a705 in ves_icall_InternalExecute (method=0x9a82108, this=0xbfffdbd8, params=0x11303578, outArgs=0xbfffdc64) at icall.c:2981
#25 0x0a9a9a18 in ?? ()
#26 0x0a9a9278 in ?? ()
#27 0x0bda8df8 in ?? ()
#28 0x0bda8c0c in ?? ()
#29 0x0bda89d0 in ?? ()
#30 0x0bda8952 in ?? ()
#31 0x0bda88c1 in ?? ()
#32 0x0bda86c9 in ?? ()
#33 0x0bda7dde in ?? ()
#34 0x0a9a7bdd in ?? ()
#35 0x0bda7b21 in ?? ()
#36 0x0bda77e2 in ?? ()
#37 0x0bda7614 in ?? ()
#38 0x0bda72f1 in ?? ()
#39 0x0a4fcf24 in ?? ()
#40 0x0a8fa1e8 in ?? ()
#41 0x0000d612 in mono_jit_runtime_invoke (method=0xce931c, obj=0x0, params=0xbfffe1ac, exc=0xbfffe1f8) at mini.c:5791
#42 0x0016d28e in mono_runtime_invoke (method=0xce931c, obj=0x0, params=0xbfffe1ac, exc=0xbfffe1f8) at object.c:2755
#43 0x0016d336 in mono_remoting_invoke (real_proxy=0x9882118, msg=0x110e0e80, exc=0xbfffe1f8, out_args=0xbfffe1f4) at object.c:5800
#44 0x001409bc in mono_remoting_wrapper (method=0xeb31eac, params=0xbfffe208) at marshal.c:2830
#45 0x0a8fa0a0 in ?? ()
#46 0x11de9ed0 in ?? ()
#47 0x11de9e14 in ?? ()
#48 0x11de9c3c in ?? ()
#49 0x11de9bfc in ?? ()
#50 0x11de9bc8 in ?? ()
#51 0x11de9b9c in ?? ()
#52 0x0e48ecf8 in ?? ()
#53 0x0e48e4b4 in ?? ()
#54 0x02ff2ba1 in ?? ()
#55 0x0000d612 in mono_jit_runtime_invoke (method=0x1fa7114, obj=0x9a4d2e8, params=0xbfffe550, exc=0x0) at mini.c:5791
#56 0x0016d28e in mono_runtime_invoke (method=0x1fa7114, obj=0x9a4d2e8, params=0xbfffe550, exc=0x0) at object.c:2755
#57 0x0014095b in mono_remoting_wrapper (method=0x1fa7114, params=0xbfffe578) at marshal.c:2825
#58 0x0a8fa0a0 in ?? ()
#59 0x0dd78274 in ?? ()
#60 0x0e46a3cb in ?? ()
#61 0x02ff2ba1 in ?? ()
#62 0x0000d612 in mono_jit_runtime_invoke (method=0x1fa6ef4, obj=0x9a4d2e8, params=0xbfffe740, exc=0x0) at mini.c:5791
#63 0x0016d28e in mono_runtime_invoke (method=0x1fa6ef4, obj=0x9a4d2e8, params=0xbfffe740, exc=0x0) at object.c:2755
#64 0x00173a48 in mono_runtime_invoke_array (method=0x10004005, obj=0x10004005, params=0x98bcab0, exc=0x0) at object.c:4142
#65 0x0011a705 in ves_icall_InternalExecute (method=0x8eda990, this=0xbfffe7c8, params=0x98bcab0, outArgs=0xbfffe854) at icall.c:2981
#66 0x0a9a9a18 in ?? ()
#67 0x0a9a9278 in ?? ()
#68 0x0bda8df8 in ?? ()
#69 0x0bda8c0c in ?? ()
#70 0x0bda89d0 in ?? ()
#71 0x0dd81b2d in ?? ()
#72 0x0bda5d99 in ?? ()
#73 0x0dd818bd in ?? ()
#74 0x0bda8534 in ?? ()
#75 0x0bda7dde in ?? ()
#76 0x0a9a7bdd in ?? ()
#77 0x0bda7b21 in ?? ()
#78 0x0bda77e2 in ?? ()
#79 0x0bda7614 in ?? ()
#80 0x0bda72f1 in ?? ()
#81 0x0a4fcf24 in ?? ()
#82 0x0a8fa1e8 in ?? ()
#83 0x0000d612 in mono_jit_runtime_invoke (method=0xce931c, obj=0x0, params=0xbfffedec, exc=0xbfffee38) at mini.c:5791
#84 0x0016d28e in mono_runtime_invoke (method=0xce931c, obj=0x0, params=0xbfffedec, exc=0xbfffee38) at object.c:2755
#85 0x0016d336 in mono_remoting_invoke (real_proxy=0xf98b118, msg=0x110e0f80, exc=0xbfffee38, out_args=0xbfffee34) at object.c:5800
#86 0x001409bc in mono_remoting_wrapper (method=0x1fa6ef4, params=0xbfffee48) at marshal.c:2830
#87 0x0a8fa0a0 in ?? ()
#88 0x0dd7741c in ?? ()
#89 0x0e731aa5 in ?? ()
#90 0x11de8ba1 in ?? ()
#91 0x11de8b1c in ?? ()
#92 0x11de89f4 in ?? ()
#93 0x09f9483c in ?? ()
#94 0x04045ea0 in g_idle_dispatch ()
#95 0x0404126e in g_main_dispatch ()
#96 0x04042afb in g_main_context_dispatch ()
#97 0x040430a3 in g_main_context_iterate ()
#98 0x040439ea in g_main_loop_run ()
#99 0x04764200 in gtk_main ()
#100 0x0db63ce4 in ?? ()
#101 0x0db63cac in ?? ()
#102 0x0db63c8c in ?? ()
#103 0x035d498c in ?? ()
#104 0x00699040 in ?? ()
#105 0x00698e0c in ?? ()
#106 0x00698ec6 in ?? ()
#107 0x0000d612 in mono_jit_runtime_invoke (method=0x90621c, obj=0x0, params=0xbffff5f8, exc=0x0) at mini.c:5791
#108 0x0016d28e in mono_runtime_invoke (method=0x90621c, obj=0x0, params=0xbffff5f8, exc=0x0) at object.c:2755
#109 0x00171354 in mono_runtime_exec_main (method=0x90621c, args=0x64fe00, exc=0x0) at object.c:3930
#110 0x00176725 in mono_runtime_run_main (method=0x90621c, argc=0, argv=0xbffff7dc, exc=0x0) at object.c:3560
#111 0x00069c15 in mono_jit_exec (domain=0x648e00, assembly=0x762ea0, argc=1, argv=0xbffff7dc) at driver.c:944
#112 0x0006c00d in mono_main (argc=3, argv=0xbffff7d4) at driver.c:1003
#113 0x00002869 in main (argc=3, argv=0xbffff7d4) at main.c:66
Comment 3 Jeffrey Stedfast 2012-02-13 11:51:46 UTC
this is probably due to my perf patch for pango trampling memory.
Comment 4 Alan McGovern 2012-02-13 11:52:20 UTC
Simplest way to make the crash dialog appear:
1) export MONODEVELOP_TEST_CRASH_REPORTING=1 in a terminal
2) Launch monodevelop from that terminal
3) Click the 'Send Feedback' button to trigger an exception
Comment 5 Mikayla Hutchinson [MSFT] 2012-02-13 11:55:09 UTC
I don't think it's Pango-related, since it happens on build 3 too.
Comment 6 Mikayla Hutchinson [MSFT] 2012-02-13 12:01:03 UTC
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x00000000
[Switching to process 26795 thread 0x8603]
0x00204782 in GC_thread_register_foreign (base_addr=0xb0308bdc) at pthread_support.c:1432
1432	pthread_support.c: No such file or directory.
	in pthread_support.c
(gdb) bt
#0  0x00204782 in GC_thread_register_foreign (base_addr=0xb0308bdc) at pthread_support.c:1432
#1  0x001ac37b in mono_thread_attach (domain=0x3cfe00) at threads.c:1048
#2  0x00008146 in mono_jit_thread_attach (domain=0x0) at mini.c:2597
#3  0x079c2ef0 in ?? ()
#4  0x90d19d11 in objc_retain ()
#5  0x98de4bfd in _Block_object_assign ()
#6  0x96b593c1 in __copy_helper_block_4 ()
#7  0x98de3f86 in _Block_call_copy_helper ()
#8  0x98de49d3 in _Block_copy_internal ()
#9  0x94ee6c74 in CFRunLoopPerformBlock ()
#10 0x966c22ad in __-[NSTextView checkTextInRange:types:options:]_block_invoke_1 ()
#11 0x966c21e9 in -[NSTextCheckingOperation performCompletionHandler] ()
#12 0x966b97dc in -[NSTextCheckingOperation main] ()
#13 0x9967837b in -[__NSOperationInternal start] ()
#14 0x99677edb in -[NSOperation start] ()
#15 0x9968c02e in ____NSOQSchedule_block_invoke_2 ()
#16 0x93fbae11 in _dispatch_call_block_and_release ()
#17 0x93fbbe70 in _dispatch_worker_thread2 ()
#18 0x958eeb24 in _pthread_wqthread ()
#19 0x958f06fe in start_wqthread ()
Comment 7 Mikayla Hutchinson [MSFT] 2012-02-13 12:10:37 UTC
To clarify, the first trace is not the crashed thread, the second is correct. So it looks like an issue in MonoMac or in the runtime.
Comment 8 Mikayla Hutchinson [MSFT] 2012-02-13 12:28:46 UTC
Isolated test case for the crash: https://gist.github.com/32c53363db43fc9b6d7c
Comment 9 Rolf Bjarne Kvinge [MSFT] 2012-02-13 17:58:36 UTC
This looks like a mono bug, and in any case I can't reproduce with tip of the 2.10 branch (but I can with the 2.10.9 release).
Comment 10 Miguel de Icaza [MSFT] 2012-02-14 11:28:50 UTC
Michael mentioned in the call that you suspected a particular commit in mono 2-10 fixed the issue.
Comment 11 Duncan Mak 2012-02-14 16:56:54 UTC
16:54 <duncan> rolf: what should we do about #3424, do you have a
               machine where you can do something like git bisect
               to pinpoint the commit?
16:54 <rolf> duncan: so the idea would be to backport it from 2.10
             HEAD to the 2.10.9 branch?
16:55 <duncan> rolf: there's also a plan to do a 2.10.10 from the
               tip of mono-2-10, but that's next week (in the
               earliest)
16:55 <rolf> I can run bisect, yes, but it'll likely take a coupl e
             hours
16:55 <duncan> right
16:55 [rolf starts]
Comment 12 Rolf Bjarne Kvinge [MSFT] 2012-02-14 17:56:31 UTC
I can not reproduce when I build 2.10.9 from source, neither with 2.10.8.1 from packages. In any case, none of the 4 commits between 2.10.8.1 and 2.10.9 should cause such a crash.
Comment 13 Duncan Mak 2012-02-14 20:36:38 UTC
18:33 <rolf> k, the commit I was talking about is
             26877fb8d4edf3ebdc32fb0c97bf7cb78af955f1
18:36 <rolf> right, enabling -O2 makes 2.10.9 crash
18:37 <rolf> let me try with that patch, now it shouldn't take long
             to compile
18:38 <rolf> and voila, now it doesn't crash anymore

I'm building a new Mono 2.10.9 with the patch now. Build #4 will go out to the beta channel tonight.
Comment 14 Alan McGovern 2012-02-14 21:29:57 UTC
*** Bug 3463 has been marked as a duplicate of this bug. ***
Comment 15 Duncan Mak 2012-02-14 23:25:36 UTC
Mono 2.10.9 (build #4) has been released to the Beta channel and it's also available on mono-project.com.