Bug 42625 - coop: crash with watchos system tests
Summary: coop: crash with watchos system tests
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler (show other bugs)
Version: master
Hardware: PC Mac OS
: --- normal
Target Milestone: WatchOS 2.0
Assignee: Aleksey Kliger
URL:
Depends on:
Blocks:
 
Reported: 2016-07-18 11:52 UTC by Rolf Bjarne Kvinge [MSFT]
Modified: 2016-07-25 15:33 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 FIXED

Description Rolf Bjarne Kvinge [MSFT] 2016-07-18 11:52:56 UTC
Repro:
* Open xamarin-macios/tests/bcl-tests/System/System-watchos.sln and run System-watchos-app in the simulator.
* This only seems to be happening with the debugger attached (you may run into #42623 first though).

Crash report & cue card: https://gist.github.com/rolfbjarne/1a82a823d3182718e15c55601f0cd1e3

Slack transcript:

Rolf Kvinge [13:22] @ludovic: I'm running into a coop bug with watchos where a threadpool thread ends up in the wrong state

>(lldb) bt
>* thread #14: tid = 0x4ca9b, 0x0022074f SystemTests`poll_event_wait(callback=<unavailable>, user_data=<unavailable>) + 15 at threadpool-ms-io-poll.c:141, name = 'tid_4eef', stop reason = breakpoint 1.1
>  * frame #0: 0x0022074f SystemTests`poll_event_wait(callback=<unavailable>, user_data=<unavailable>) + 15 at threadpool-ms-io-poll.c:141
>    frame #1: 0x00220232 SystemTests`selector_thread(data=0x00000000) + 1314 at threadpool-ms-io.c:424
>    frame #2: 0x0022e00f SystemTests`start_wrapper [inlined] start_wrapper_internal + 546 at threads.c:741
>    frame #3: 0x0022dded SystemTests`start_wrapper(data=<unavailable>) + 29 at threads.c:789
>    frame #4: 0x00296b9a SystemTests`inner_start_thread(arg=<unavailable>) + 458 at mono-threads-posix.c:95
>    frame #5: 0x0862c780 libsystem_pthread.dylib`_pthread_body + 138
>    frame #6: 0x0862c6f6 libsystem_pthread.dylib`_pthread_start + 155
>    frame #7: 0x08629f7a libsystem_pthread.dylib`thread_start + 34

Rolf Kvinge [13:23]  state = 0x105

Ludovic Henry [13:23]  it should be `BLOCKING`
Ludovic Henry [13:23]  I am on FTO right now, but will take a look
Ludovic Henry [13:24]  it' missing BLOCKING transition

Rolf Kvinge [13:31]  only seems to happen when the debugger is attached though
Rolf Kvinge [13:41]  looks like the `selector_thread` method starts with state=0x1 and never enters the blocking state before waiting
Comment 1 Aleksey Kliger 2016-07-19 19:38:34 UTC
Fixed on mono master 44d346f73a684738c00775c1fd6ee56877019898
Fixed on mono mono-4.6.0-branch f1417d0c92ea51477eb1080a1a3c0611f253149d

Pull request to bump watch-mono for xamarin-macios master is https://github.com/xamarin/xamarin-macios/pull/434
Pull request to bump watch-mono for xamarin-macios cycle8 is https://github.com/xamarin/xamarin-macios/pull/436
Comment 2 Aleksey Kliger 2016-07-25 15:33:27 UTC
xamarin-macios master 17335b5271c16389da9cd3265e96fcd091f7a859
xamarin-macios cycle8 276d4de9a99b495dd0501c4e0e268018a94557b7