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
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.
Created attachment 124 [details]
apple error report
Went to a movie, came back, MD was crashed.
The crash reports don't help - they contain no info from the .NET side :/
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)
*** Bug 289 has been marked as a duplicate of this bug. ***
Nat, which kind of project were you working on? MonoMac, MonoTouch?
Waiting on Nat.
It was a C# commandline project.
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?
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.
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.
*** Bug 1457 has been marked as a duplicate of this bug. ***
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.
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
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.
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
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
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.
Has this patch resolved the issue? If so has it been committed and can i close the bug?
I no longer get it in MD 2.8 and MT 5.0
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.