Bug 13612 - Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `result' not met
Summary: Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `re...
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 6.3.x
Hardware: Macintosh Mac OS
: --- critical
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
: 13714 ()
Depends on:
Blocks:
 
Reported: 2013-07-30 11:20 UTC by Chris Hardy [MSFT]
Modified: 2013-09-27 05:48 UTC (History)
11 users (show)

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


Attachments
Crash from Case 42483 (4.18 KB, text/plain)
2013-08-01 08:44 UTC, Allie Miller
Details
Test Project from Case 42483 (4.19 KB, application/zip)
2013-08-01 12:29 UTC, Allie Miller
Details


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 Chris Hardy [MSFT] 2013-07-30 11:20:33 UTC
The following crash: Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `result' not met

happens on code that works as expected on Xamarin.iOS 6.2, but causes this problem on Xamarin.iOS 6.4
Comment 4 Rodrigo Kumpera 2013-07-31 13:51:07 UTC
The issue is in NSObject::InvokeInBackground, as a workaround, use the C# facilities for that. Such as ThreadPool.QueueUserWorkItem, Task.Run or simply create a new Thread.
Comment 5 Miguel de Icaza [MSFT] 2013-07-31 13:54:58 UTC
One issue we found: InvokeInBackground creates a new thread eveyr time, which is very expensive.

So people should instead use the ThreadPool whenever possible.
Comment 8 Allie Miller 2013-08-01 08:44:51 UTC
Created attachment 4509 [details]
Crash from Case 42483
Comment 9 Allie Miller 2013-08-01 12:29:59 UTC
Created attachment 4512 [details]
Test Project from Case 42483
Comment 11 Rolf Bjarne Kvinge [MSFT] 2013-08-02 21:29:13 UTC
*** Bug 13714 has been marked as a duplicate of this bug. ***
Comment 12 Rolf Bjarne Kvinge [MSFT] 2013-08-13 04:54:18 UTC
Workaround for NSObject.InvokeInBackground (use System.Threading.Thread instead) committed.

monotouch/master: 893a76b17a33232d342d22404a9ce36996cd940e
monotouch/monotouch-6.4-series: 4f106f29fe6b28386601159171984bf960e795ab

Fix for NSThread is still pending.
Comment 14 Rolf Bjarne Kvinge [MSFT] 2013-08-14 07:44:47 UTC
Reopening since only a workaround has been committed.
Comment 16 Miguel de Icaza [MSFT] 2013-08-26 12:06:17 UTC
The simple INvokeOnBackgroundThread went out in 6.4.3.

The case for the manual Thread case is still not handled.
Comment 17 Matthijs Koopman 2013-09-13 09:56:50 UTC
Is there an ETA for the fix causing crashes when manually starting a thread?
Comment 18 Miguel de Icaza [MSFT] 2013-09-13 10:06:23 UTC
Not yet.   For now use System.Threading.Thread.
Comment 19 Matthijs Koopman 2013-09-13 11:34:40 UTC
The same issue seem to be occurring using System.Treading.Thread

So to be clear, in what's cases should this issue occur?
Comment 20 Miguel de Icaza [MSFT] 2013-09-13 11:46:29 UTC
System.Threading.Thread is not affected, perhaps another bit of your code was using either NSThread or InvokeInBackground (that one was fixed)
Comment 21 Matthijs Koopman 2013-09-13 13:10:08 UTC
@Miguel

Well that is strange, I've search through our entire solution and besides System.Threading.Thread and System.Threading.Tasks.Task we dont use anything else. So nothing like NSThread or InvokeInBackground.
Comment 22 Miguel de Icaza [MSFT] 2013-09-13 13:13:43 UTC
Then that is likely a different reason.

Please file a complete bug report with your version numbers, SDK versions, ideally the test case and so on.
Comment 23 Matthijs Koopman 2013-09-13 13:15:10 UTC
Ok, will do.

I'll try to create a propper testcase.
Comment 24 Miguel de Icaza [MSFT] 2013-09-16 10:16:10 UTC
Then that is likely a different reason.

Please file a complete bug report with your version numbers, SDK versions, ideally the test case and so on.
Comment 25 Jonas Sourlier 2013-09-24 03:14:55 UTC
My app sometimes crashes in the simulator with this error message (mono-thread.c:155, condition 'result' not met).

My app makes use of DispatchQueues, most of the time there are three queues running simultaneously, like three threads. Then I searched my solution for InvokeInBackground, but found none. The only references to other libraries are bindings to native ObjC libraries, so I'm pretty sure my app does not call Mono's NSObject wrappers.

Also, the crash occurs *sometimes*. There's no way to deterministically reproduce it.

Also, before the crash happens, there are some error logs like this:

failed to suspend thread 0xb033c000, hopefully it is dead
Comment 26 Matthijs Koopman 2013-09-24 03:16:24 UTC
I can confirm that behavior, I also do sometimes see messages like "failed to suspend thread 0xb033c000, hopefully it is dead"
Comment 27 Rolf Bjarne Kvinge [MSFT] 2013-09-27 05:48:42 UTC
NSThread's initWithTarget:selector:object: has been fixed too now.

maccore/master: 545943301075d0713005163f31a00a0efa14b691
monotouch/master: caf4dbcd1456bff3d0e6026eaca4d003771128c3