Bug 292 - Crash while idle 2.6 RC1
Summary: Crash while idle 2.6 RC1
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 2.6 Beta 3
Hardware: PC Mac OS
: Highest normal
Target Milestone: ---
Assignee: Bugzilla
: 289 ()
Depends on:
Blocks: 1120
  Show dependency tree
Reported: 2011-08-13 10:23 UTC by Nat Friedman
Modified: 2012-01-03 14:38 UTC (History)
10 users (show)

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

apple error report (66.63 KB, text/plain)
2011-08-13 10:23 UTC, Nat Friedman
Patch fixing the crash (3.86 KB, patch)
2011-11-04 09:20 UTC, Michael Natterer

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:

Description Nat Friedman 2011-08-13 10:23:47 UTC
Created attachment 124 [details]
apple error report

Went to a movie, came back, MD was crashed.
Comment 1 Mike Krüger 2011-08-15 01:26:05 UTC
The crash reports don't help - they contain no info from the .NET side :/
Comment 2 Mike Krüger 2011-08-15 01:31:00 UTC
btw. forgot to add: that's the type of crashes that should never happen in a managed environment.
(Thats one of the main reasons using VMs like java/.NET)

These should always be tracked by a managed exception - microsoft does that somehow. At least I didn't have had any native exception doing dumb things with windows forms.

This special crash looks like a gtk main loop crash (like Bug 289 - 2.6 rc1 crash while cursoring left)
Comment 3 Mike Krüger 2011-08-15 01:31:47 UTC
*** Bug 289 has been marked as a duplicate of this bug. ***
Comment 4 Lluis Sanchez 2011-08-16 12:02:21 UTC
Nat, which kind of project were you working on? MonoMac, MonoTouch?
Comment 5 Admin 2011-08-30 11:44:16 UTC
Waiting on Nat.
Comment 6 Nat Friedman 2011-08-30 11:47:16 UTC
It was a C# commandline project.
Comment 7 Kristian Rietveld (inactive) 2011-09-09 02:33:49 UTC
Is it certain the GTK+ main loop is actually causing this crash?  If I look at the upper portion of the stack trace of the crashed thread:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x98cbc9c6 __pthread_kill + 10
1   libsystem_c.dylib             	0x93e35f78 pthread_kill + 106
2   libsystem_c.dylib             	0x93e26bdd abort + 167
3   monodevelop                   	0x000ba874 0x1000 + 759924
4   libsystem_c.dylib             	0x93e8b59b _sigtramp + 43
5   ???                           	0xffffffff 0 + 4294967295
6   com.apple.CoreFoundation      	0x92b919ea __CFRunLoopServiceMachPort + 170
7   com.apple.CoreFoundation      	0x92b9ab14 __CFRunLoopRun + 1428
8   com.apple.CoreFoundation      	0x92b9a1ec CFRunLoopRunSpecific + 332
9   com.apple.CoreFoundation      	0x92b9a098 CFRunLoopRunInMode + 120
10  com.apple.HIToolbox           	0x90d21487 RunCurrentEventLoopInMode + 318
11  com.apple.HIToolbox           	0x90d28dc3 ReceiveNextEventCommon + 381
12  com.apple.HIToolbox           	0x90d28c32 BlockUntilNextEventMatchingListInMode + 88
13  com.apple.AppKit              	0x94b036c0 _DPSNextEvent + 678
14  com.apple.AppKit              	0x94b02f2d -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
15  libgdk-quartz-2.0.0.dylib     	0x036859ba poll_func + 282
16  libglib-2.0.0.dylib           	0x0353be9f g_main_context_poll + 280

then to me it looks like GTK+ has gracefully requested the next event in frame 14 and is waiting for that (through nextEventMatchingMask:untilDate:...).  At frame 4, a signal seems to have come in which is apparently being handled by managed code in frame 3.  I get the impression the managed code is triggering abort() which terminates the process.

Is this a plausible scenario?
Comment 8 Mikayla Hutchinson [MSFT] 2011-09-09 09:53:56 UTC
Good point about frame 3, not sure how I missed that. Pretty sure it's inside the Mono runtime though, not managed code. Need to get a trace with symbols.
Comment 9 Mikayla Hutchinson [MSFT] 2011-10-12 15:05:19 UTC
Actually, I'm gonna call this as a GTK or Mono runtime bug again. Frame 3 is the Mono sigsegv signal handler. Something's causing the sigsegv.
Comment 10 Mikayla Hutchinson [MSFT] 2011-10-12 15:06:03 UTC
*** Bug 1457 has been marked as a duplicate of this bug. ***
Comment 11 Mikayla Hutchinson [MSFT] 2011-10-22 10:23:56 UTC
From looking around, it seems that crashes in the CFRunLoop can actually be caused by other threads. The first two traces have a thread running OSACompile, which seems suspicious.
Comment 12 Mikayla Hutchinson [MSFT] 2011-10-22 13:24:01 UTC
I can't find any docs on using OSA from threads, but Apple's AppleScript Editor does run OSAExecute from a thread. Maybe it's the OSACompile call rather than OSA in general that's causing issues? Some mailings lists seem to indicate that OSA compilation leaks. We might eb able to improve the situation by any of
(a) compiling the scripts and keeping them and the component handle around
(b) sending AppleEvents directly using Carbon API
(c) sending AppleEvents using the NSAppleEventDescriptor Cocoa wrappers
(d) running AppleEvents in the GUI thread, though this is a last resort as it would deadlock the GUI
Comment 13 Mike Krüger 2011-10-24 03:26:54 UTC
*** Bug 1457 has been marked as a duplicate of this bug. ***
Comment 14 Mikayla Hutchinson [MSFT] 2011-10-26 13:54:45 UTC
I've been prototyping a direct binding to low-level AppleEvents but I fear that will be very hard to use, since AE API is explicitly marked as threadsafe on 10.2+. I've also been prototyping a tool to generate a ScripingBridge wrapper for the Xcode AE API, which is more promising.
Comment 15 Michael Natterer 2011-11-04 09:20:59 UTC
Created attachment 822 [details]
Patch fixing the crash

The problem is clearly in gdkeventloop-quartz.c, it totally messes its
state when getting the next event creates a recursive main loop inside
the framework. 

Attached patch fixes main loop depth tracking, and turns the getting_events
boolean into a counter so it works recursively. The patch seems to fix
DND completely.
Comment 16 Michael Natterer 2011-11-04 09:27:40 UTC
This patch was actually meant for bug #1120, but the stack trace here
has a recursive main loop, triggered by getting events, so I'm pretty
sure it fixes this bug too.
Comment 17 Alan McGovern 2011-11-14 17:00:28 UTC
Has this patch resolved the issue? If so has it been committed and can i close the bug?
Comment 18 Ian 2011-11-14 17:16:20 UTC
I no longer get it in MD 2.8 and MT 5.0
Comment 19 Mikayla Hutchinson [MSFT] 2012-01-03 14:38:44 UTC
This should be fixed by the GTK+ version that's currently in Mono beta, so I'm marking it fixed. Please re-open if it happens with GTK+ version is 2.24.8 or later. GTK+ version can be found in the MD About dialog.