Bug 15824 - Random crashes in unmanaged code
Summary: Random crashes in unmanaged code
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 7.0.2.x
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2013-10-30 12:06 UTC by Jeffrey Voorhaar
Modified: 2015-03-05 09:49 UTC (History)
5 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 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 Jeffrey Voorhaar 2013-10-30 12:06:10 UTC

I am having a lot of stability issues with my iOS builds the last couple of weeks. Currently using Xamarin.iOS I have an unhandled exception handler on the appdomain which doesn't get the chance to do anything. My app just randomly crashes (both on the device and the simulator, both in debug and release mode) and this is all I get for a stack trace:


Thread started: <Thread Pool> #9
Thread started: <Thread Pool> #10
Thread started: <Thread Pool> #11
Thread started: <Thread Pool> #12
Thread finished: <Thread Pool> #6
Thread finished: <Thread Pool> #6
Thread started:  #13
failed to suspend thread 0xb049d000, hopefully it is dead
* Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `result' not met

Native stacktrace:

mono-rt: 	0   ReeleezeeMobileCashRegisteriOS      0x0018ad8d mono_handle_native_sigsegv + 349

mono-rt: 	1   ReeleezeeMobileCashRegisteriOS      0x00195d9a sigabrt_signal_handler + 122

mono-rt: 	2   libsystem_c.dylib                   0x0584d94b _sigtramp + 43

mono-rt: 	3   ???                                 0xffffffff 0x0 + 4294967295

mono-rt: 	4   libsystem_sim_c.dylib               0x054f0e12 abort + 127

mono-rt: 	5   ReeleezeeMobileCashRegisteriOS      0x002d6745 monoeg_g_logv + 181

mono-rt: 	6   ReeleezeeMobileCashRegisteriOS      0x002d67ab monoeg_assertion_message + 43

mono-rt: 	7   ReeleezeeMobileCashRegisteriOS      0x002cc04d mono_thread_info_attach + 445

mono-rt: 	8   ReeleezeeMobileCashRegisteriOS      0x002cbc35 inner_start_thread + 37

mono-rt: 	9   ReeleezeeMobileCashRegisteriOS      0x002ed28d GC_start_routine + 93

mono-rt: 	10  libsystem_c.dylib                   0x058615b7 _pthread_start + 344

mono-rt: 	11  libsystem_c.dylib                   0x0584bdce thread_start + 34

Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.


I have found a lot of related reports by others, but none seem to match my situation exactly. And as such, no proposed solution actually made a difference for me.

Any clues on how to get stable iOS builds again?

Please note that Android builds using the same code seem to be a lot more stable.

Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-10-31 08:46:04 UTC
Would it be possible to get access to your project so we can reproduce this?
Comment 5 Rolf Bjarne Kvinge [MSFT] 2013-11-05 03:59:14 UTC
That's good to hear :)

Unfortunately this isn't really something you can debug on your own - a colleague of mine spent two days a couple of months ago tracking down a similar assertion, so I knew roughly where to look, but it did involve adding logging to the mono runtime and using gdb on device (in short not really something we expect our customers to be able to do). In any case each crash is different, and the method I used to track this down is not necessarily the easiest/best way to track down another crash.

The best way to solve any crash you can't easily figure out yourself is to create a bug report here with a test case so that we can have a look at it. We have a significant experience in diagnosing crashes, and in some cases we'll instantly see the problem when it would take you days or weeks to figure out what's going on.
Comment 6 Jeffrey Voorhaar 2013-11-05 04:17:01 UTC
I see. I do feel that I should in fact be able to at least pinpoint it more accurately, so I'll look into the use of gdb on devices. At the very least, it'll be interesting to do :)
Comment 7 T.J. Purtell 2014-01-05 17:05:53 UTC
I was running into this issue and found  a few causes.  Perhaps these will help you in searching your own code for a cause.

1. There were NSNotificationCenter AddObserver calls that were using the selector version of the call.
2. Some of these observers were not unregistered properly.
3. Some UIGestureRecognizers, UIButtons, etc which had C# event or action callbacks were allocated as local variables and not as fields of the C# view controller that contained them.  (My understanding is that in order to break reference cycles, there is no back pointer keeping the C# object alive)

Resolving all of these made the assertion go away for me.  Interestingly, I found another bug report where someone reported this error going away (mostly) when they effectively switched from new Thread(() => {}).Start() to Task.Run(() => {}).  I was already using the thread pool, but I realized I was making the thread pool get unnecessarily large by running synchronous network operations from Tasks.  After I rewrote the networking layer of the app to use only asynchronous networking inside the thread pool, the occurrences of this error dropped dramatically.  I thought I was experiencing a bug in mono where thread pool pressure was causing a race condition (the message sounds like a failure in mono after all).  My best guess at this point is that thread pool pressure causes new pool threads to be created and destroyed and that the garbage collector is kicked off as a result of this activity.  So, basically I had reduced the amount of garbage dramatically which helped to hide the error (that a managed peer of a NSSomething was GCed and the NSSomething tried to invoke a callback via the collected managed peer).

One of the techniques I used to help reproduce was to run a thread which just GC's every N milliseconds.  This made it much easier to discover the first screen of the app that had an obvious error.  Then it was helpful in verifying that the modifications eliminated the error.

It would be nice if it was easier to know this was the problem.  The error message made me hunt for very different kind of failures in mono itself instead. But now I know.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2015-03-05 09:49:40 UTC
It looks like we've fixed the NSThreadWillExitNotification some time ago, in any case I can't reproduce any crashes anymore.