Bug 14721 - 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 NORESPONSE
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.4.4
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-09-13 13:19 UTC by Matthijs Koopman
Modified: 2016-05-24 20:07 UTC (History)
3 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 NORESPONSE

Description Matthijs Koopman 2013-09-13 13:19:09 UTC
In extend to the bugreport already being filed under (#13612) there seems to be another case where the following SIGSEV will be thrown:

Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `result' not met

I'm using the latest statble version of Xamarin.IOS (6.4.5) and the Mono Framework 3.2.0 / 3.2.2

So this issue seems to occur when calling back from a separate thread to the main thread, or thats what it looks like. So far i don't have a testcase that i'm able to submit but I'll try to upload one as soon as possible.
Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-09-25 08:40:56 UTC
Waiting for test case.
Comment 2 Matthijs Koopman 2013-09-30 03:24:16 UTC
Here is some additional info:

Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Critical>: * Assertion at ../../../../../mono/mono/utils/mono-threads.c:155, condition `result' not met
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 
	Native stacktrace:
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	0   MyApp                          0x010a3f33 MyApp + 16744243
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	1   MyApp                          0x010a8c57 MyApp + 16763991
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	2   libsystem_platform.dylib            0x38654723 _sigtramp + 42
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	3   libsystem_pthread.dylib             0x38659a53 pthread_kill + 58
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	4   libsystem_c.dylib                   0x385a302d abort + 76
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	5   MyApp                          0x01116dc7 MyApp + 17214919
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	6   MyApp                          0x0111314b MyApp + 17199435
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	7   MyApp                          0x01112ee9 MyApp + 17198825
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	8   MyApp                          0x011205ab MyApp + 17253803
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	9   libsystem_pthread.dylib             0x38658c5d <redacted> + 140
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	10  libsystem_pthread.dylib             0x38658bcf _pthread_start + 102
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 	11  libsystem_pthread.dylib             0x38656cd0 thread_start + 8
Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Error>: 
	=================================================================
	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.
	=================================================================
Comment 3 Rolf Bjarne Kvinge [MSFT] 2013-09-30 04:18:16 UTC
My guess would be that this is the cause:

Sep 30 09:15:51 iPhone-van-Matthijs-Koopman MyApp[2671] <Warning>:
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set
CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.

Can you try setting CA_DEBUG_TRANSACTIONS in your app (you can do this in the project's options, Run/General page [1])?

[1] Please verify that the environment variable was set correctly after dismissing the dialog (by reopening the dialog again), sometimes Xamarin Studio will not save it properly.
Comment 4 Matthijs Koopman 2013-09-30 04:22:55 UTC
There you go:

Sep 30 10:21:09 iPhone-van-Matthijs-Koopman MyApp[2794] <Warning>: CoreAnimation: warning, deleted thread with uncommitted CATransaction; created by:
	0   QuartzCore                          0x3014a6a5 <redacted> + 268
	1   QuartzCore                          0x3014a559 <redacted> + 224
	2   QuartzCore                          0x3014abbb <redacted> + 30
	3   QuartzCore                          0x30154aef <redacted> + 42
	4   QuartzCore                          0x30154aa3 <redacted> + 94
	5   UIKit                               0x304cb2e5 <redacted> + 172
	6   UIKit                               0x3059fcd1 <redacted> + 64
	7   MyApp                          0x00f37a3c MyApp + 15301180
	8   MyApp                          0x00eda8d4 MyApp + 14919892
	9   MyApp                          0x00250ea0 MyApp + 1773216
	10  MyApp                          0x00257850 MyApp + 1800272
	11  MyApp                          0x0011a724 MyApp + 501540
	12  MyApp                          0x0068af40 MyApp + 6205248
	13  MyApp                          0x006af918 MyApp + 6355224
	14  MyApp                          0x00b50ce8 MyApp + 11209960
	15  MyApp                          0x00c3114c MyApp + 12128588


However I should note that when using ThreadPool.QueueUserWorkItem instead of new Thread(() => { ; }) the amount of crashes seems to be dramatically lower.
Comment 5 Matthijs Koopman 2013-09-30 05:52:07 UTC
A little update, I have replaced almost all the "new Thread(() => { ; }).Start()" code with "ThreadPool.QueueUserWorkItem(new WaitCallback((state) => { ; }));" and the number of crashes is almost zero, the ones still occurring might be related to some code that I did not yet replaced with the threadpool.

However when I switch back to using threads, the issues immediately starts occuring again.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2013-09-30 08:17:13 UTC
I believe you're doing something wrong wrt animations, and the reason it works with the threadpool is because you happen to reuse the same thread at a later stage, instead of creating a new one.

The stack trace from comment #4 would likely have shown you where the problem is, had it been properly symbolicated. Is this a debug/release, device/sim? And what's the OSX version you're running on?

Otherwise this might help to fix the <redacted> parts: http://stackoverflow.com/q/12809174/183422
Comment 7 Matthijs Koopman 2013-09-30 08:56:56 UTC
It is a release device build.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2013-09-30 09:04:20 UTC
Can you try a debug+device build to see if you get a better stack trace? If that doesn't work I believe the best is to try to create a small test case.
Comment 10 Rolf Bjarne Kvinge [MSFT] 2013-09-30 09:22:21 UTC
How big is your app? Do you have the linker enabled (in the project's iOS Build options, set "Linker behavior" = "Link all assemblies")?
Comment 12 Matthijs Koopman 2013-09-30 10:01:49 UTC
What I don't get is why this always worked without any issues, now when upgrading to the latest version of Xamarin.IOS i get all these crashes, so is there anything different regarding animations in the latest version?
Comment 13 Rolf Bjarne Kvinge [MSFT] 2013-09-30 10:37:20 UTC
There are two separate issues, which are very likely related:

* The warning about animations ("warning, deleted thread with uncommitted CATransaction;") - I do not know if this is a new warning in iOS7 (did you see it earlier too?), but in any case it's a problem in your code and it should be fixed. Note also that this is a warning from Apple/iOS, not Xamarin, so we don't control this.

* The crash you're experiencing. In bug #13612 this happened because managed code was executed on a thread that had started its shutdown (in particular from a tls destructor), and we lost track of which threads was still executing. This sounds like it is related to the problem with animations above (the "deleted thread" part from the warning), which is why I recommend you fix the warning first, since it may very well solve your problem with the crash. Something that may have changed in the latest version of Xamarin.iOS is that we trigger the crash condition in our runtime easier, but that doesn't mean the problem didn't exist earlier, just that you didn't happen to hit the crash condition.
Comment 14 Sebastien Pouliot 2016-05-24 20:07:51 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!