Xamarin-macios: [Bug] IOS13 terminates app when backgrounded location services is requested
Description
A Xamarin app that on IOS uses the location services is terminated not long after being backgrounded. Termination only occurs on IOS13 and not on IOS12 and 11.
Steps to Reproduce
The repo app here is the simple File->new XF master detail app.
The code I use to implement the IOS Location services is the sample XF walk-though code from
https://docs.microsoft.com/en-us/xamarin/ios/app-fundamentals/backgrounding/ios-backgrounding-walkthroughs/location-walkthrough
I do nothing more than subscribe to location services and print to the console when I receive location updates.
- https://github.com/Chris-Marassovich/IOSLocationTest
- Run/Debug app on a iPhone.
On start-up app will request Location permission. Accept the "Allow While Using App" option.
Even though in code I request "Always in Background" this is where IOS13 varies as it will not request that permission upfront.
It will wait till the app is backgrounded before requesting that permission level.
In the device console you can see that the "locationd" process in IOS is happily delivering locations to the app.Send app to background. I tap the home button.
At this point I see the following in the debug console. Note this message has only started to appear with the GM and did not appear with the beta's of IOS.
I have no idea what this means or indicates. It does not appear in IOS12 or 11.
Can't end BackgroundTask: no background task exists with identifier 1 (0x1), or it may have already been ended. Break in UIApplicationEndBackgroundTaskError() to debug.
- At this point note that in the Device Console (on your mac) the "locationd" process is still happily sending background locations to the app BUT note that they are "provisional" as the user has yet to be asked or responded to the "always background" permission.
Interesting point is if you stay at this stage the app does not get terminated and is happily sent location updates, although provisional, in the background for many hours.
I gave up waiting/watching.
Of course being able to stay in this state is not a viable solution as the user will eventually respond to the permission request. - This is the critical step in getting the issue to occur.
You need to trigger IOS to request the "Always in Background" permission.
Unlock the device (if required), you may have to bring the app to the foreground and send it to the background to trigger the request.
IOS will now request the "Allow access to your location in the background". Take the "Change to always" option.
If needed send the app to the background. I also lock the devices screen.
During the next 1 to 5 minutes the following will occur. The time may vary for you.
In the Debug console I get the following:
=================================================================
Native Crash Reporting
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
Native stacktrace:
=================================================================
Note there is no stacktrace produced.
Some more time goes by (for me 10 seconds) and the following is in the Debug console:
The app has been terminated.
Failed to Stop app: An error occurred on client IDB1630274 while executing a reply for topic xvs/idb/16.3.0.274/stop-app
The app has been terminated.
Over in the Device Console on your mac there are many interesting lines that make no sense to me.
Messages about excessive CPU usage by the app.
and then a Death Sentinel fired and app terminated.
The app works fine on IOS 12 and 11 but on 13 this occurs.
Of course in the LocationManager class (LocationManager.cs) if I do not start the location services LocMgr.StartUpdatingLocation(); or I set LocMgr.AllowsBackgroundLocationUpdates = false;
the app termination never occurs but the point of this is to obtain location updates while app is backgrounded.
I believe the code I am using is correct as it was taken from the Xamarin walk-throughs. :-)
I hope you can shed some light on what or where I can look for more info to resolve this.
Expected Behavior
App is not terminated when backgrounded and continues to receive location updates. This is how it works on IOS12 and 11.
Actual Behavior
App is terminated by OS sometime after being backgrounded.
Basic Information
- Version with issue: IOS13
- Last known good version: IOS12
Xcode : 11.0 (11A420a)
Microsoft Visual Studio Professional 2019
Version 16.3.1
VisualStudio.16.Release/16.3.1+29324.140
Microsoft .NET Framework
Version 4.8.03752
Installed Version: Professional
Application Insights Tools for Visual Studio Package 9.1.00913.1
Application Insights Tools for Visual Studio
ASP.NET and Web Tools 2019 16.3.283.64955
ASP.NET and Web Tools 2019
ASP.NET Web Frameworks and Tools 2019 16.3.283.64955
For additional information, visit https://www.asp.net/
Azure App Service Tools v3.0.0 16.3.283.64955
Azure App Service Tools v3.0.0
Azure Functions and Web Jobs Tools 16.3.283.64955
Azure Functions and Web Jobs Tools
C# Tools 3.3.1-beta3-19461-02+2fd12c210e22f7d6245805c60340f6a34af6875b
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.
Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.
GitHub.VisualStudio 2.10.4.8063
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.
IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed Info
Microsoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 0x10 - v2.9.20816.1
Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.
Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines
Microsoft Library Manager 2.0.83+gbc8a4b23ec
Install client-side libraries easily to any web project
Microsoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggers
Microsoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.
Mono Debugging for Visual Studio 16.3.7 (9d260c5)
Support for debugging Mono processes with Visual Studio.
NuGet Package Manager 5.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/
ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed Info
SQL Server Data Tools 16.0.61908.27190
Microsoft SQL Server Data Tools
TypeScript Tools 16.0.10821.2002
TypeScript Tools for Microsoft Visual Studio
Visual Basic Tools 3.3.1-beta3-19461-02+2fd12c210e22f7d6245805c60340f6a34af6875b
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.
Visual F# Tools 10.4 for F# 4.6 16.3.0-beta.19455.1+0422ff293bb2cc722fe5021b85ef50378a9af823
Microsoft Visual F# Tools 10.4 for F# 4.6
Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio
Visual Studio Spell Check Everywhere VSSpellCheckEverywhere
An extension that enables spell checking within any Visual Studio file editor or tool window that uses WPF text boxes.
https://GitHub.com/EWSoftware/VSSpellChecker
Visual Studio Spell Checker VSSpellChecker
An editor extension that checks the spelling of comments, strings, and plain text as you type or interactively with tool windows.
https://GitHub.com/EWSoftware/VSSpellChecker
Visual Studio Tools for Containers 1.0
Visual Studio Tools for Containers
VisualStudio.Mac 1.0
Mac Extension for Visual Studio
Xamarin 16.3.0.274 (d16-3@06531f8)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.
Xamarin Designer 16.3.0.230 (remotes/origin/d16-3-xcode11@bbe518670)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.
Xamarin Templates 16.3.565 (27e9746)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.
Xamarin.Android SDK 10.0.0.43 (d16-3/8af1ca8)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: mono/mono/2019-06@7af64d1ebe9
Java.Interop: xamarin/java.interop/d16-3@5836f58
LibZipSharp: grendello/LibZipSharp/d16-3@71f4a94
LibZip: nih-at/libzip/rel-1-5-1@b95cf3f
ProGuard: xamarin/proguard/master@905836d
SQLite: xamarin/sqlite/3.27.1@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-3@cb41333
Xamarin.iOS and Xamarin.Mac SDK 13.2.0.42 (5e8a208)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
- Affected Devices:
Tested against iPhone devices running IOS 12 and IOS 13.
Reproduction Link
Chris-Marassovich
All 32 comments
I tried reproducing this locally and had difficulty.
It could be due to a missing entitlement
Can you please attach a crash report with symbols applied?
chamons
on 30 Sep 2019
@chamons thanks for a quick response.
I have a few points I would like to raise for us to discuss so please be patient with me. I really need to resolve this issue as background location updates is a feature of our app.
It is a shame you were unable to reproduce the issue. I stress that you needed to follow my reproduction steps. Step 6 is the critical step to reproduce the issue. Before that step under the provisional location permission the app will not be terminated and continues for as long as I was willing to wait. It is after step 6 when you grant the "always" permission to the app it then gets terminated after a period.
I have this issue on two separate iPhones running IOS13. One has a release build and the other has a debug build. I have reset one phone back to IOS12 and the issue was not present .. upgraded that phone to IOS13 and the issue was present. I think that indicates my hardware is not the issue. Can you share with me what device you tested with? I assume you tested on a real device as I understand simulators do not act the same way when your dealing with location services.
Missing entitlement. What do you mean by that? Can you explain what you are getting at with that please? Are we not both using the same solution and hence the entitlements.plist is the same? I assume when you say entitlements you mean the plist file?
I am very happy to supply crash reports with symbols applied. Can you point me to some documentation on exactly how to do that please? I am relatively new to Xamarin mobile dev and I am not too strong in the Mac/IOS tooling. I do have over 25 years of software dev .. just relatively new to mobile dev.
My thinking on my next steps.
We are both using the same solution, both using real devices and both followed the same reproduction steps. If that is true then it would indicate that the difference is my build chain. I have no idea where to start looking there for issues as my VS windows install is quite standard and the Xcode upgrade on the Mac was quite straight forward.
My next step, apart from getting you those crash reports, is to get a build from AppCenter and get that onto my devices. That would prove if my build chain is the source of the issue. What do you think about that as a next step?
Cheers
Chris ...
Chris-Marassovich
on 1 Oct 2019
@chamons I just created a new app for this test case in App Center so I could build and distribute it from there. This was to eliminate any build pipeline settings/config at my end being the source of the issue.
It did take me some time to get the profiles and certificates right but I did get a build and distributed it to my device.
App Center must do something different as the install and app run do not prompt for location permissions.
The good thing is the app does show the issue at hand. It took over 3 minutes to occur but it did get terminated.
I had to open the app, send it to the background, then bring it to foreground and send it back again to the background.
You get a number of messages in the Device console on the Mac around the location process and then after 3 minutes it is terminated.
- I can save out the Device Console logs and attach them?
- I can upload the ipa here for you to install?
- I can add your account to the distribution group in App Center?
Which do you prefer? or all 3?
Cheers
Chris ...
PS In the actual app (not this sample for testing) I have App Center crash analytics configured and when this issue occurs there is nothing reported in App Center.
Chris-Marassovich
on 1 Oct 2019
@chamons Attached is the Device Console logs showing the termination.
It is filtered to only show entries containing the app name.
Chris-Marassovich
on 1 Oct 2019
These are the interesting lines:
default 14:42:00.711556 +1000 runningboardd [application<com.companyname.IOSLocationTest>:417] Death sentinel fired!
default 14:42:00.720034 +1000 symptomsd Received (FATAL) CPU usage trigger:
IOSLocationTest.iOS[417] (/private/var/containers/Bundle/Application/7806475F-0530-4C32-84E5-FEE81B316F74/IOSLocationTest.iOS.app/IOSLocationTest.iOS) used 48.00s of CPU over 54.58 seconds (averaging 87%), violating a CPU usage limit of 48.00s over 60 seconds.
This means that the app used too much CPU and that iOS decided to kill it.
Exactly which device did you reproduce this on?
rolfbjarne
on 1 Oct 2019
@rolfbjarne thanks for the reply.
Firstly please note some details about the app. See the repo link as it is just the standard XF file new master detail app and which implements the sample code from location services walkthrough from the XF site. Very simple and I have no idea how it could possibly use that amount of CPU.
My primary device is an iPhone 6s Plus running IOS13.
If I restore this device to IOS12 the app works fine and the issue does not occur.
It has been run on a iPhone X (IOS13) and it shows the same issue.
Your help is appreciated.
Cheers
Chris ...
Chris-Marassovich
on 1 Oct 2019
I'm experiencing the same message
Can't end BackgroundTask: no background task exists with identifier 8 (0x8), or it may have already been ended. Break in UIApplicationEndBackgroundTaskError() to debug.
viktorszekeress
on 1 Oct 2019
I tried the app on my iPhone X with iOS 13.1, and it still hasn't crashed after 3.5 hours.
@Chris-Marassovich can you profile your app with Instruments (open Instruments, select the Time Profiling template, then your device + app, and finally profile) until it crashes, and then save the Instruments trace and attach it here?
rolfbjarne
on 1 Oct 2019
App didn't crash on my simulator either. I just saw that message in the output.
It occurred on iPhone 8 iOS 13.0 simulator, but not on real device iPhone 6 iOS 12.4.2.
I was wondering if background tasks are even supported on a simulator, is it documented somewhere?
viktorszekeress
on 1 Oct 2019
I tried the app on my iPhone X with iOS 13.1, and it still hasn't crashed after 3.5 hours.
@Chris-Marassovich can you profile your app with Instruments (open Instruments, select the Time Profiling template, then your device + app, and finally profile) until it crashes, and then save the Instruments trace and attach it here?
@rolfbjarne please find attached the instrument log using the Time Profiling template. Took me a little while to find it and use it
all. Learning some good stuff. Thanks
Instruments.trace.zip
Also I was worried that the issue may be with my build process and I got a build of the repo in App Center so i can upload that ipa or add you to the App Center group as that ipa crashes for me.
Chris-Marassovich
on 2 Oct 2019
App didn't crash on my simulator either. I just saw that message in the output.
It occurred on iPhone 8 iOS 13.0 simulator, but not on real device iPhone 6 iOS 12.4.2.
I was wondering if background tasks are even supported on a simulator, is it documented somewhere?
@viktorszekeress My understanding is sims are pretty much the same as a device until you use hardware related services such as location services and then it is always best to use a device.
That message does only occur on IOS13. Not sure if it is in anyway related to this issue but many people are seeing this and it is causing them issues with their apps being backgrounded and then resuming. Some links for your reference.
https://forums.developer.apple.com/thread/121990
https://forums.developer.apple.com/thread/22836
Chris-Marassovich
on 2 Oct 2019
@rolfbjarne @viktorszekeress How are you guys running the app?
Is it via a debug session from VS2019 or some other method?
When I run it from a VS debug session to a device the order and steps are quite critical. Initially the app has not yet received the "always run in background" permission and in that moment while it will receive location updates in the background they are "provisional" and in that state the app does not get terminated. It will run for hours. Once you interact with the device/app IOS will prompt for the permission and then the app will be terminated (after a period of minutes) once backgrounded. This is detailed in Step 6 of my original post.
Yet when I got a build from App Center and distributed it via App Center to the same device it did not ask for those permissions but it certainly was terminated when I backgrounded the app and locked the device.
I am trying to figure out why I am seeing this and you guys are not.
Chris-Marassovich
on 2 Oct 2019
That was very interesting!
This is the stack trace of the code that consumes CPU:
1. 48.70 s 100.0% 0 s IOSLocationTest.iOS (594)
2. 47.86 s 98.2% 0 s _dispatch_workloop_worker_thread 0x2ca5b
3. 47.86 s 98.2% 0 s _pthread_wqthread
4. 47.86 s 98.2% 0 s _dispatch_workloop_worker_thread
5. 47.86 s 98.2% 0 s _dispatch_lane_invoke$VARIANT$mp
6. 47.86 s 98.2% 0 s _dispatch_lane_serial_drain$VARIANT$mp
7. 47.86 s 98.2% 0 s _dispatch_mach_invoke$VARIANT$mp
8. 47.86 s 98.2% 0 s _dispatch_lane_serial_drain$VARIANT$mp
9. 47.86 s 98.2% 0 s _dispatch_mach_msg_invoke$VARIANT$mp
10. 47.86 s 98.2% 0 s _dispatch_client_callout4
11. 47.86 s 98.2% 0 s _xpc_connection_mach_event
12. 47.86 s 98.2% 0 s _xpc_connection_call_event_handler
13. 47.86 s 98.2% 0 s 0x1921c0644
14. 47.86 s 98.2% 0 s 0x1921be568
15. 47.86 s 98.2% 0 s CLConnection::handleMessage(std::__1::shared_ptr<CLConnectionMessage>)
16. 47.86 s 98.2% 0 s 0x1921c4e04
17. 47.86 s 98.2% 0 s 0x1921c4f20
18. 47.86 s 98.2% 0 s 0x18dfbd740
19. 47.86 s 98.2% 0 s CLConnectionMessage::getObjectOfClasses(NSSet*) const
20. 47.86 s 98.2% 0 s -[NSCoder decodeTopLevelObjectOfClasses:forKey:error:]
21. 47.86 s 98.2% 0 s -[NSCoder(Exceptions) __tryDecodeObjectForKey:error:decodeBlock:]
22. 47.86 s 98.2% 0 s -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:]
23. 47.86 s 98.2% 0 s -[NSKeyedUnarchiver decodeObjectForKey:]
24. 47.86 s 98.2% 0 s _decodeObject
25. 47.86 s 98.2% 0 s _decodeObjectBinary
26. 47.86 s 98.2% 0 s NSClassFromString
27. 47.86 s 98.2% 0 s look_up_class
28. 47.86 s 98.2% 0 s getClassExceptSomeSwift(char const*)
29. 47.86 s 98.2% 0 s getPreoptimizedClass
30. 47.86 s 98.2% 0 s dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const
31. 47.86 s 98.2% 0 s dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long, unsigned long> > const&, void (void*, bool, bool*) block_pointer) const
32. 47.86 s 98.2% 0 s dyld3::closure::ObjCStringTable::getIndex(char const*) const
33. 47.86 s 98.2% 0 s _sigtramp
34. 47.86 s 98.2% 0 s 0x103d9bfc2
35. 47.86 s 98.2% 0 s 0x103d8d782
36. 47.86 s 98.2% 0 s 0x103d979f6
37. 47.86 s 98.2% 0 s dladdr
38. 47.86 s 98.2% 0 s dyld3::dladdr(void const*, dl_info*)
39. 47.86 s 98.2% 0 s dyld3::AllImages::infoForImageMappedAt(void const*, dyld3::MachOLoaded const**, unsigned long long*, char const**) const
40. 47.86 s 98.2% 0 s dyld3::AllImages::infoForNonCachedImageMappedAt(void const*, void (dyld3::LoadedImage const&, unsigned char) block_pointer) const
41. 47.86 s 98.2% 0 s invocation function for block in dyld3::AllImages::infoForNonCachedImageMappedAt(void const*, void (dyld3::LoadedImage const&, unsigned char) block_pointer) const
42. 47.86 s 98.2% 0 s invocation function for block in dyld3::AllImages::infoForNonCachedImageMappedAt(void const*, void (dyld3::LoadedImage const&, unsigned char) block_pointer) const
43. 47.86 s 98.2% 47.86 s dyld3::closure::Image::containsAddress(void const*, void const*, unsigned char*) const
It seems that iOS crashes (frame 33, _sigtramp), and then the execution goes into the app (frames 34-36) before the app calls dladdr (frame 37) and that ends up running into an infinite loop deep in the bowels of dyld (frame 43).
Unfortunately the frames 34-36 don't contain symbol information. Could you uncheck the Strip native debugging information from the project's iOS Build options, rebuild and try again? That should produce more informative stack traces.
rolfbjarne
on 2 Oct 2019
@rolfbjarne I am very appreciative of your time and knowledge in this space. This level of debug information is very new to me.
Attached is a new instrument log using the Time Profiling template where the
Strip Native debugging symbols was unchecked in the IOS project prior to build.
I did note that on this test run the app ran in the background for a much longer period before termination. Maybe that is simply due to more debug information?
I look forward to your analysis on this file.
Chris-Marassovich
on 3 Oct 2019
Unfortunately that didn't make those frames symbolicated :/
Let's try something different: if you add the following line of code at the very beginning of your Main method (so that it's executed at startup), those frames shouldn't be hit in the first place, and hopefully the app will crash immediately with a crash report:
static void Main (string[] args)
{
Mono.Runtime.RemoveSignalHandlers ();
// ...
}
Could you try this, and when it crashes, get the crash report from Xcode's Organizer (open Xcode, menu Window -> Devices and Simulators, select your device on the left and the click "View Device Logs" on the right, and then Xcode will download the crash reports from the device (this may take a few seconds)).
rolfbjarne
on 3 Oct 2019
@rolfbjarne Sorry for the delay. Locally it was a long weekend and access to my build environment was not possible.
Here is the crash log from a run before I made your suggested changes.
IOSLocationTest.iOS 8-10-19, 11-11 am.crash.zip
and here is the crash log after a run with your suggested changes of adding
Mono.Runtime.RemoveSignalHandlers ();
IOSLocationTest.iOS 8-10-19, 11-17 am.crash.zip
I hope this provides you with some more information.
Chris-Marassovich
on 8 Oct 2019
It looks like somebody else has the same problem on Apple's forums: https://forums.developer.apple.com/thread/122858.
As such this does not look like a bug in Xamarin.iOS, and my suggestion would be to file a bug with Apple (some people from that forum post have already filed bugs, but Apple prioritizes bugs based on the number of duplicates, so the more people file the same bug, the faster they'll fix it).
rolfbjarne
on 8 Oct 2019
@rolfbjarne Thanks for that link.
Did those crash reports give you any further information or insight?
The URL to the Apple Forums ..... can you shed a little more light on why you think these are similar to my issue please?
While there are some similarities they are talking about an app crash while I beleive my app is being terminated. Is that a significant difference?
Also in regard to the location permission while the app has the "provisional" permission it is not terminated and happily runs in the background for as long as I could wait. Only after the user grants the "always" permission and the provisional one is removed are we terminated once backgrounded.
I am still trying to chase down the state and details on the bug reports from the URL.
I appreciate your insight on this.
Chris-Marassovich
on 9 Oct 2019
can you shed a little more light on why you think these are similar to my issue please
Because the thread that crashed has a _very_ similar stack trace.
Yours:
Thread 1 name: Dispatch queue: com.apple.CoreLocation.0x10822a4e0
Thread 1 Crashed:
0 libdyld.dylib 0x000000019b7896c0 dyld3::closure::ObjCStringTable::hash+ 14016 (char const*, unsigned long) const + 16
1 libdyld.dylib 0x000000019b789cd4 dyld3::closure::ObjCStringTable::getIndex+ 15572 (char const*) const + 52
2 libdyld.dylib 0x000000019b789b54 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long, unsigned long> > const&, void + 15188 (void*, bool, bool*) block_pointer) const + 52
3 libdyld.dylib 0x000000019b7964f8 dyld3::AllImages::forEachObjCClass(char const*, void + 66808 (void*, bool, bool*) block_pointer) const + 132
4 libobjc.A.dylib 0x000000019b6c8c38 getPreoptimizedClass + 148
5 libobjc.A.dylib 0x000000019b6b38d8 getClassExceptSomeSwift+ 51416 (char const*) + 20
6 libobjc.A.dylib 0x000000019b6b4784 look_up_class + 100
7 Foundation 0x000000019bd46b00 NSClassFromString + 200
8 Foundation 0x000000019bd37264 _decodeObjectBinary + 1708
9 Foundation 0x000000019bd36928 _decodeObject + 340
10 Foundation 0x000000019bc46050 -[NSKeyedUnarchiver decodeObjectForKey:] + 168
11 Foundation 0x000000019bc45eac -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 352
12 Foundation 0x000000019bc45b04 -[NSCoder+ 68356 (Exceptions) __tryDecodeObjectForKey:error:decodeBlock:] + 96
13 Foundation 0x000000019bc45a7c -[NSCoder decodeTopLevelObjectOfClasses:forKey:error:] + 108
14 LocationSupport 0x00000001a2ca0170 CLConnectionMessage::getObjectOfClasses+ 45424 (NSSet*) const + 176
15 CoreLocation 0x000000019ea9d820 0x19ea95000 + 34848
16 LocationSupport 0x00000001a2ca4f64 0x1a2c95000 + 65380
17 LocationSupport 0x00000001a2ca4e90 0x1a2c95000 + 65168
18 LocationSupport 0x00000001a2c9e6ec CLConnection::handleMessage+ 38636 (std::__1::shared_ptr<CLConnectionMessage>) + 180
19 LocationSupport 0x00000001a2c9e5a4 0x1a2c95000 + 38308
20 LocationSupport 0x00000001a2ca0828 0x1a2c95000 + 47144
21 libxpc.dylib 0x000000019b55254c _xpc_connection_call_event_handler + 68
22 libxpc.dylib 0x000000019b5528c4 _xpc_connection_mach_event + 876
23 libdispatch.dylib 0x000000019b652244 _dispatch_client_callout4 + 16
24 libdispatch.dylib 0x000000019b60eba4 _dispatch_mach_msg_invoke$VARIANT$mp + 380
25 libdispatch.dylib 0x000000019b5fe330 _dispatch_lane_serial_drain$VARIANT$mp + 300
26 libdispatch.dylib 0x000000019b60f7a4 _dispatch_mach_invoke$VARIANT$mp + 472
27 libdispatch.dylib 0x000000019b5fe330 _dispatch_lane_serial_drain$VARIANT$mp + 300
28 libdispatch.dylib 0x000000019b5fee58 _dispatch_lane_invoke$VARIANT$mp + 420
29 libdispatch.dylib 0x000000019b608340 _dispatch_workloop_worker_thread + 588
30 libsystem_pthread.dylib 0x000000019b6a1fa4 _pthread_wqthread + 276
31 libsystem_pthread.dylib 0x000000019b6a4ae0 start_wqthread + 8
Theirs (from https://forums.developer.apple.com/thread/122858#382710):
Thread 14 name:
Thread 14 Crashed:
0 libdyld.dylib 0x00000001a38356c0 dyld3::closure::ObjCStringTable::hash(char const*, unsigned long) const + 16 (Closure.cpp:1339)
1 libdyld.dylib 0x00000001a3835cd4 dyld3::closure::ObjCStringTable::getIndex(char const*) const + 52 (Closure.h:840)
2 libdyld.dylib 0x00000001a3835b54 dyld3::closure::ObjCClassOpt::forEachClass(char const*, dyld3::Array<std::__1::pair<unsigned long... + 52 (Closure.cpp:1397)
3 libdyld.dylib 0x00000001a38424f8 dyld3::AllImages::forEachObjCClass(char const*, void (void*, bool, bool*) block_pointer) const + 132 (AllImages.cpp:1922)
4 libobjc.A.dylib 0x00000001a3774c38 getPreoptimizedClass + 148 (objc-opt.mm:279)
5 libobjc.A.dylib 0x00000001a375f8d8 getClassExceptSomeSwift(char const*) + 20 (objc-runtime-new.mm:1607)
6 libobjc.A.dylib 0x00000001a3760784 look_up_class + 100 (objc-runtime-new.mm:6843)
7 Foundation 0x00000001a3df2b00 NSClassFromString + 200 (NSObjCRuntime.m:0)
8 Foundation 0x00000001a3de3264 _decodeObjectBinary + 1708 (NSKeyedArchiver.m:2472)
9 Foundation 0x00000001a3de2928 _decodeObject + 340 (NSKeyedArchiver.m:3013)
10 Foundation 0x00000001a3cf2050 -[NSKeyedUnarchiver decodeObjectForKey:] + 168 (NSKeyedArchiver.m:3035)
11 Foundation 0x00000001a3cf1eac -[NSKeyedUnarchiver decodeObjectOfClasses:forKey:] + 352 (NSKeyedArchiver.m:3069)
12 Foundation 0x00000001a3cf1b04 -[NSCoder(Exceptions) __tryDecodeObjectForKey:error:decodeBlock:] + 96 (NSCoder.m:557)
13 Foundation 0x00000001a3cf1a7c -[NSCoder decodeTopLevelObjectOfClasses:forKey:error:] + 108 (NSCoder.m:360)
14 LocationSupport 0x00000001aad4b170 CLConnectionMessage::getObjectOfClasses(NSSet*) const + 176 (CLConnection.mm:690)
15 CoreLocation 0x00000001a6b4890c invocation function for block in _CLClientCreateConnection(__CLClient*) + 224 (CLClient.mm:1155)
16 LocationSupport 0x00000001aad4ff64 invocation function for block in CLConnectionClient::setDefaultMessageHandler(void (std::__1::sha... + 68 (CLConnectionClient.mm:379)
17 LocationSupport 0x00000001aad4fe90 invocation function for block in CLConnectionClient::setDefaultMessageHandler(void (std::__1::sha... + 140 (CLCallbackDropManager.h:46)
18 LocationSupport 0x00000001aad496ec CLConnection::handleMessage(std::__1::shared_ptr<CLConnectionMessage>) + 180 (CLConnection.mm:232)
19 LocationSupport 0x00000001aad495a4 invocation function for block in CLConnection::initializeConnection_nl() + 60 (CLConnection.mm:210)
20 LocationSupport 0x00000001aad4b828 invocation function for block in setEventHandler(NSObject<OS_xpc_object>*, void (std::__1::shared... + 484 (CLConnection.mm:348)
21 libxpc.dylib 0x00000001a35fe54c _xpc_connection_call_event_handler + 68 (connection.c:0)
22 libxpc.dylib 0x00000001a35fe8c4 _xpc_connection_mach_event + 876 (connection.c:1208)
23 libdispatch.dylib 0x00000001a36fe244 _dispatch_client_callout4 + 16 (object.m:535)
While there are some similarities they are talking about an app crash while I beleive my app is being terminated. Is that a significant difference?
That's just the same thing said two different ways.
Only after the user grants the "always" permission and the provisional one is removed are we terminated once backgrounded.
I believe this is because the crash occurs after the app gets a particular notification, and that particular notification is probably only happening after you've granted the "always" permission. I don't know how this notification is different from the provisional ones.
rolfbjarne
on 9 Oct 2019
@rolfbjarne thanks for the insight. It is very appreciated.
Most of the posters there seemed to workaround the issue by setting the disk protection from NSFileProtectionComplete to NSFileProtectionCompleteUntilFirstUserAuthentication in their entitlements. I followed this workaround and it did not workaround the issue for me.
I have raised a feedback to apple on this … feels a lot like placing a message into a bottle … I think this step must be completed and at some point it becomes a bug report .. and then .... :-) as I said feels like "a message in bottle" with apple.
Chris-Marassovich
on 9 Oct 2019
I have raised a feedback to apple on this … feels a lot like placing a message into a bottle … I think this step must be completed and at some point it becomes a bug report .. and then .... :-) as I said feels like "a message in bottle" with apple.
Some of the bug reports I've created with Apple have been fixed, so while it can certainly feel like sending a message in a bottle, the bottle is sometimes opened and the message read :smile:
rolfbjarne
on 9 Oct 2019
I have raised a feedback to apple on this … feels a lot like placing a message into a bottle … I think this step must be completed and at some point it becomes a bug report .. and then .... :-) as I said feels like "a message in bottle" with apple.
Some of the bug reports I've created with Apple have been fixed, so while it can certainly feel like sending a message in a bottle, the bottle is sometimes opened and the message read 😄
:-) my use of that term was a comment on the submission process itself and not on how that message may or may not be received or processed. No malice intended here towards anyone.
The point on this is my lack of understanding … I am not sure how I track my feedback now that it has been submitted. Where do I go to see that and possibly escalate or iterate on it? Something I need work out.
Chris-Marassovich
on 9 Oct 2019
Description
A Xamarin app that on IOS uses the location services is terminated not long after being backgrounded. Termination only occurs on IOS13 and not on IOS12 and 11.
Steps to Reproduce
The repo app here is the simple File->new XF master detail app.
The code I use to implement the IOS Location services is the sample XF walk-though code from
https://docs.microsoft.com/en-us/xamarin/ios/app-fundamentals/backgrounding/ios-backgrounding-walkthroughs/location-walkthrough
I do nothing more than subscribe to location services and print to the console when I receive location updates.
- https://github.com/Chris-Marassovich/IOSLocationTest
- Run/Debug app on a iPhone.
- On start-up app will request Location permission. Accept the "Allow While Using App" option.
Even though in code I request "Always in Background" this is where IOS13 varies as it will not request that permission upfront.
It will wait till the app is backgrounded before requesting that permission level.
In the device console you can see that the "locationd" process in IOS is happily delivering locations to the app.- Send app to background. I tap the home button.
At this point I see the following in the debug console. Note this message has only started to appear with the GM and did not appear with the beta's of IOS.
I have no idea what this means or indicates. It does not appear in IOS12 or 11.
Can't end BackgroundTask: no background task exists with identifier 1 (0x1), or it may have already been ended. Break in UIApplicationEndBackgroundTaskError() to debug.
- At this point note that in the Device Console (on your mac) the "locationd" process is still happily sending background locations to the app BUT note that they are "provisional" as the user has yet to be asked or responded to the "always background" permission.
Interesting point is if you stay at this stage the app does not get terminated and is happily sent location updates, although provisional, in the background for many hours.
I gave up waiting/watching.
Of course being able to stay in this state is not a viable solution as the user will eventually respond to the permission request.- This is the critical step in getting the issue to occur.
You need to trigger IOS to request the "Always in Background" permission.
Unlock the device (if required), you may have to bring the app to the foreground and send it to the background to trigger the request.
IOS will now request the "Allow access to your location in the background". Take the "Change to always" option.If needed send the app to the background. I also lock the devices screen.
During the next 1 to 5 minutes the following will occur. The time may vary for you.
In the Debug console I get the following:
================================================================= Native Crash Reporting ================================================================= Got a SIGSEGV while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. ================================================================= ================================================================= Native stacktrace: =================================================================Note there is no stacktrace produced.
Some more time goes by (for me 10 seconds) and the following is in the Debug console:
The app has been terminated. Failed to Stop app: An error occurred on client IDB1630274 while executing a reply for topic xvs/idb/16.3.0.274/stop-app The app has been terminated.Over in the Device Console on your mac there are many interesting lines that make no sense to me.
Messages about excessive CPU usage by the app.
and then a Death Sentinel fired and app terminated.The app works fine on IOS 12 and 11 but on 13 this occurs.
Of course in the LocationManager class (LocationManager.cs) if I do not start the location services
LocMgr.StartUpdatingLocation();or I setLocMgr.AllowsBackgroundLocationUpdates = false;
the app termination never occurs but the point of this is to obtain location updates while app is backgrounded.
I believe the code I am using is correct as it was taken from the Xamarin walk-throughs. :-)I hope you can shed some light on what or where I can look for more info to resolve this.
Expected Behavior
App is not terminated when backgrounded and continues to receive location updates. This is how it works on IOS12 and 11.
Actual Behavior
App is terminated by OS sometime after being backgrounded.
Basic Information
- Version with issue: IOS13
- Last known good version: IOS12
Xcode : 11.0 (11A420a)
Microsoft Visual Studio Professional 2019
Version 16.3.1
VisualStudio.16.Release/16.3.1+29324.140
Microsoft .NET Framework
Version 4.8.03752Installed Version: Professional
Application Insights Tools for Visual Studio Package 9.1.00913.1
Application Insights Tools for Visual StudioASP.NET and Web Tools 2019 16.3.283.64955
ASP.NET and Web Tools 2019ASP.NET Web Frameworks and Tools 2019 16.3.283.64955
For additional information, visit https://www.asp.net/Azure App Service Tools v3.0.0 16.3.283.64955
Azure App Service Tools v3.0.0Azure Functions and Web Jobs Tools 16.3.283.64955
Azure Functions and Web Jobs ToolsC# Tools 3.3.1-beta3-19461-02+2fd12c210e22f7d6245805c60340f6a34af6875b
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.Common Azure Tools 1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.Extensibility Message Bus 1.2.0 (d16-2@8b56e20)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.GitHub.VisualStudio 2.10.4.8063
A Visual Studio Extension that brings the GitHub Flow into Visual Studio.IntelliCode Extension 1.0
IntelliCode Visual Studio Extension Detailed InfoMicrosoft Azure Tools 2.9
Microsoft Azure Tools for Microsoft Visual Studio 0x10 - v2.9.20816.1Microsoft Continuous Delivery Tools for Visual Studio 0.4
Simplifying the configuration of Azure DevOps pipelines from within the Visual Studio IDE.Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual MachinesMicrosoft Library Manager 2.0.83+gbc8a4b23ec
Install client-side libraries easily to any web projectMicrosoft MI-Based Debugger 1.0
Provides support for connecting Visual Studio to MI compatible debuggersMicrosoft Visual Studio Tools for Containers 1.1
Develop, run, validate your ASP.NET Core applications in the target environment. F5 your application directly into a container with debugging, or CTRL + F5 to edit & refresh your app without having to rebuild the container.Mono Debugging for Visual Studio 16.3.7 (9d260c5)
Support for debugging Mono processes with Visual Studio.NuGet Package Manager 5.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/ProjectServicesPackage Extension 1.0
ProjectServicesPackage Visual Studio Extension Detailed InfoSQL Server Data Tools 16.0.61908.27190
Microsoft SQL Server Data ToolsTypeScript Tools 16.0.10821.2002
TypeScript Tools for Microsoft Visual StudioVisual Basic Tools 3.3.1-beta3-19461-02+2fd12c210e22f7d6245805c60340f6a34af6875b
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.Visual F# Tools 10.4 for F# 4.6 16.3.0-beta.19455.1+0422ff293bb2cc722fe5021b85ef50378a9af823
Microsoft Visual F# Tools 10.4 for F# 4.6Visual Studio Code Debug Adapter Host Package 1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual StudioVisual Studio Spell Check Everywhere VSSpellCheckEverywhere
An extension that enables spell checking within any Visual Studio file editor or tool window that uses WPF text boxes.
https://GitHub.com/EWSoftware/VSSpellCheckerVisual Studio Spell Checker VSSpellChecker
An editor extension that checks the spelling of comments, strings, and plain text as you type or interactively with tool windows.
https://GitHub.com/EWSoftware/VSSpellCheckerVisual Studio Tools for Containers 1.0
Visual Studio Tools for ContainersVisualStudio.Mac 1.0
Mac Extension for Visual StudioXamarin 16.3.0.274 (d16-3@06531f8)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.Xamarin Designer 16.3.0.230 (remotes/origin/d16-3-xcode11@bbe518670)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.Xamarin Templates 16.3.565 (27e9746)
Templates for building iOS, Android, and Windows apps with Xamarin and Xamarin.Forms.Xamarin.Android SDK 10.0.0.43 (d16-3/8af1ca8)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: mono/mono@7af64d1
Java.Interop: xamarin/java.interop@5836f58
LibZipSharp: grendello/LibZipSharp/d16-3@71f4a94
LibZip: nih-at/libzip@b95cf3f
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools@cb41333Xamarin.iOS and Xamarin.Mac SDK 13.2.0.42 (5e8a208)
Xamarin.iOS and Xamarin.Mac Reference Assemblies and MSBuild support.
- Affected Devices:
Tested against iPhone devices running IOS 12 and IOS 13.Reproduction Link
Hi Same issue I have faced but with audio playing with timer synch, and app works on all previous os and gets stops in ios 13 in lock screen mode only, after 10 seconds.
In my case following are the steps.
I have 10 mp3 files arrond 30 seconds duration for each.
In every minute start, I have to play a single file, then remaining seconds will be silence. so when next minute start needs to play the next audio file.
and that process should be run for 10 minutes for those 10 audio files.
but the app getting paused after 10 seconds when the app is in lock screen mode.
and when I am opening the lock of device then app starts again with resumed timer and audio.
rahultiwari007
on 15 Oct 2019
@rahultiwari007 that sounds like a different problem, so if you want us to have a look at it please file a new issue and include a project we can use to reproduce the problem.
rolfbjarne
on 15 Oct 2019
@rahultiwari007 that sounds like a different problem, so if you want us to have a look at it please file a new issue and include a project we can use to reproduce the problem.
both are the same issue related to background mode of ios 13, either we use location or audio play, both modes get stopped after 10 seconds in the background.
rahultiwari007
on 15 Oct 2019
For anyone's reference on this I have:
- Raised a feedback issue to Apple. Ref FB7360532
- Raised a Technical Support Incident (TSI). Doco states only after raising a bug can one do this … but no detail on how to raise a bug. I assume the FB becomes a bug at some point?
I have heard nothing to date on the TSI. If people are interested I can keep you posted here?
Chris ...
Chris-Marassovich
on 16 Oct 2019
2. I assume the FB becomes a bug at some point?
I believe the feedback issue is the bug TSI refers to. I don't know of any other way to report a bug with Apple.
If people are interested I can keep you posted here?
That would be great.
rolfbjarne
on 16 Oct 2019
some good news this morning.
Apple support requested I test on iOS 13.2 beta 3 (17B5077a) which only became available to me this morning.
I am pleased to say that my reproduction solution does not show the issue as reported. It stays up and running (receiving location updates) in the background.
The app would be terminated within a 2 to 5 minute window and it has been running for hours at this point.
It is working as expected.
I appreciate the assistance I received here. Thanks guys.
Chris-Marassovich
on 17 Oct 2019
That's great! Thanks for letting us know. I'll close this then!
rolfbjarne
on 17 Oct 2019
some good news this morning.
Apple support requested I test on iOS 13.2 beta 3 (17B5077a) which only became available to me this morning.
I am pleased to say that my reproduction solution does not show the issue as reported. It stays up and running (receiving location updates) in the background.
The app would be terminated within a 2 to 5 minute window and it has been running for hours at this point.It is working as expected.
I appreciate the assistance I received here. Thanks guys.
hi Chris, so you havent updated anything in code? any background task related code have you written ?
rahultiwari007
on 17 Oct 2019
@rahultiwari007 that's correct the test app was completely unchanged from the start. All I did was upgrade my device to the latest beta that was released just this morning.
Chris-Marassovich
on 17 Oct 2019
@Chris-Marassovich & @rahultiwari007
I wanna thank y’all, Esp u Chris as I could find nothing on the Internet when I searched...
< “backgrounded the app" error in iOS 13, terminates app. > ...
... for every single game that’s still playable through game Center! So frustrating and I have no idea how to write code for mobile stuff but your entry here Chris was the only thing I could find anywhere in the using the same words… I’m in 13.31 and it just sucks rat’s ass With all the crashes. I can rarely get through a whole game without a massive freeze and then I keep waiting for my opponents to play and sure enough that stupid “backgrounded” error comes up after a minute or more
For someone who has no idea what they’re doing right now do you have any advice for what I can say to Apple or anything I can do in my settings to fix this? Neither of these two apps that are crashing require location approval as location would be irrelevant for them but can you advise me in any way shape or form how fix this damn thing?
Apple as usual plays dumb when I call about it, Or acts like I’m the only person in the world they’ve ever heard this from… Like it’s a user issue…
I hope you see this to maybe reply but I want to thank you all so so much For your posts and
comments as they let me know I was not nuts
If either of you are kind enough to reply would you mind shooting me an email? As I don’t come here and would have no idea of ur reply otherwise ... Thanks again to everyone in the thread. Y’all are the best
AnythingButAverage@ gmail
🙏 😊
BecCanDo
on 17 Sep 2020
Related issues
mrward
·
4Comments
juepiezhongren
·
3Comments
wcoder
·
3Comments
whitneyschmidt
·
3Comments
rolfbjarne
·
4Comments
Most helpful comment
For anyone's reference on this I have:
I have heard nothing to date on the TSI. If people are interested I can keep you posted here?
Chris ...