Bug 35200 - This target doesn't support mono_arch_setup_async_callback
Summary: This target doesn't support mono_arch_setup_async_callback
Alias: None
Product: iOS
Classification: Xamarin
Component: Mono runtime / AOT compiler ()
Version: XI 8.10
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Zoltan Varga
Depends on:
Reported: 2015-10-23 09:37 UTC by John Miller [MSFT]
Modified: 2015-10-26 14:27 UTC (History)
4 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 John Miller [MSFT] 2015-10-23 09:37:57 UTC

   After invoking a Thread.Abort() from the main thread (this thread is used to handle communication to a server through a TcpSocket) a customer app crashes on 64-bit devices. 

**Steps to Reproduce:**

   The customer is able to reproduce this only on 64 bit devices, and only when using an app deployed from the App Store using 8.10. 
   To be clear, it seems they only have an app deployed to the store with 8.10. 
   They have tested with the latest Alpha builds (9.2?) locally and are not able to reproduce. They have also tested with the same 8.10 builds, and are not able to reproduce locally. It happens only from App Store, on first launch of the app. 

**Actual Results:**

   App crashes on first launch. See the attached crash logs. 

**Expected Results:**

   No crash.

**Build Date & Platform:**

   iOS 8 / 9
Comment 3 Rodrigo Kumpera 2015-10-23 12:15:02 UTC
A a workaround, don't use Thread.Abort, it's a bad idea as it can break the process beyond repain.
Comment 4 Guillaume 2015-10-23 12:32:24 UTC
@Rodrigo as I mentioned to John in original issue reporting, we are aware of Thread.Abort issues. But prior to fix it, we would like to better understand the complex reproduction context we are facing in order to properly test potential fixes.

This part of code is really crucial in our framework and has been running for years in our original WinForm app without any issue. We are planning to update it in a relative "near" future but we cannot propagate this change on all platforms without being able to properly test it.

If you can at least help us to better understand what is happening and find a way to reproduce it locally, it will be greatly appreciated :)
Comment 5 Rodrigo Kumpera 2015-10-23 15:55:04 UTC
Should be trivial to repro.

This is an iOS 64bits only issue, we have a better Thread.Abort implementation on 32bits.

Get 2 threads.

On thread 1 run this:
while (true) ;

On thread 2 call Thread.Abort on thread 1 once you're sure it is running the above code - a sleep of a couple second after spawning should do it.

And that's it. Aborting a thread running in managed code won't work on 64bits iOS.

How hard would it be for you to work around this issue?

We can consider adding this to our roadmap.
Comment 6 Zoltan Varga 2015-10-23 19:24:41 UTC
Fixed in mono master 348c46afceff6156c1fc13ab53f473165a1f98ef/mono-extensions master 7ed09f9e90cc1c8ebbffe073bcf3df90a594e310.
Comment 7 Guillaume 2015-10-26 14:14:26 UTC
Thanks for the fix!!

Regarding your comment about 32bits implementation vs 64bits, I think I will also consider refactor our code to avoid Thhread.Abort usage :)
Comment 8 Rodrigo Kumpera 2015-10-26 14:27:03 UTC
I strongly suggest doing so. Thread.Abort is very hard to implement correctly on the runtime side and even worse on the C# side give it interrupts code at arbitrary points, which can lead to memory leak and corrupted state.