Bug 27233 - CRASH: SleepEx method triggers an assertion, which aborts the application
Summary: CRASH: SleepEx method triggers an assertion, which aborts the application
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: XI 8.6.0
Hardware: All Other
: Normal minor
Target Milestone: Untriaged
Assignee: Rodrigo Kumpera
URL:
Depends on:
Blocks:
 
Reported: 2015-02-19 15:24 UTC by David O'Connor
Modified: 2016-04-14 06:01 UTC (History)
7 users (show)

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


Attachments
here's a sample report from this crash (57.65 KB, text/plain)
2015-02-19 16:55 UTC, David O'Connor
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 David O'Connor 2015-02-19 15:24:42 UTC
We see around 200 crashes per day with the following callstack (as reported by HockeyApp);

1	libsystem_kernel.dylib	__pthread_kill + 8
2	libsystem_pthread.dylib	pthread_kill + 60
3	libsystem_c.dylib	abort + 74
4	KingsRoad_iOS	log_callback (runtime.m:817)
5	KingsRoad_iOS	log_adapter (mono-logger.c:278)
6	KingsRoad_iOS	monoeg_assertion_message (goutput.c:113)
7	KingsRoad_iOS	SleepEx (wthreads.c:93)
8	KingsRoad_iOS	monitor_thread (threadpool.c:909)
9	KingsRoad_iOS	start_wrapper (threads.c:663)
10	KingsRoad_iOS	inner_start_thread (mono-threads-posix.c:88)
11	libsystem_pthread.dylib	_pthread_body + 136
12	libsystem_pthread.dylib	_pthread_start + 116
13	libsystem_pthread.dylib	thread_start + 6

The only code we have even vaguely related to this is where we set the thread pool size;

			System.Threading.ThreadPool.SetMaxThreads (6, 4);		// default is (200, 8)
			System.Threading.ThreadPool.SetMinThreads (6, 4);		// default is (2, 4)

We chose these numbers empirically based on measured performance on low-end iOS devices. Specifically these numbers give us the best performance on iPad 2 and iPad Mini 1.  Not sure if setting these is even related to the crash however.

App is KingsRoad:
https://itunes.apple.com/us/app/kingsroad/id722565423?mt=8
Comment 1 Sebastien Pouliot 2015-02-19 16:37:12 UTC
That does not looks like this is coming from the main thread. Do you have a more complete crash report from HockeyApp ?
Comment 2 Sebastien Pouliot 2015-02-19 16:39:58 UTC
static WapiHandle_thread*
lookup_thread (HANDLE handle)
{
	WapiHandle_thread *thread;
	gboolean ok;

	ok = _wapi_lookup_handle (handle, WAPI_HANDLE_THREAD,
							  (gpointer *)&thread);
	g_assert (ok);
	return thread;
}

^ that's the assert being hit

@Rodrigo ever seen something similar ?
Comment 3 David O'Connor 2015-02-19 16:55:07 UTC
Created attachment 9934 [details]
here's a sample report from this crash
Comment 4 Sebastien Pouliot 2015-02-19 20:27:23 UTC
Thanks! That gives a lot more information.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2015-02-23 05:06:54 UTC
David, fwiw this crash does not have any impact on your users, it's crashing when the app is already exiting (iow there is no visible difference for app users).
Comment 6 David O'Connor 2015-02-23 15:50:45 UTC
makes sense;  would be nice for the mono shutdown to be 'clean' and not generate a crash report. But this is minor.
Comment 7 Rodrigo Kumpera 2015-07-27 11:51:50 UTC
Hey Ludovic,

This should eventually be addressed by the io-layer work you'd been doing.
Comment 8 Rodrigo Kumpera 2016-04-14 06:01:30 UTC
We now properly cleanup the monitor thread.