-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS 14.2 app crashes if deployed via mdm but not from appstore #10086
Comments
I am experiencing the same issue with Xamarin.iOS (14.4.1.3) apps as well. The app crash only occurs if the app is deployed via MDM (AirWatch) from the App Store and does not occur if the app is built as an IPA and deployed via MDM. The following workaround resolves the app crash:
|
The app are build identically for AppStore / AdHoc / MDM. The @kodejack can you open the console app and give us the logs from the device where this happens (between the app start and it's crash 20 seconds later). It's possible that either us, some 3rd party or the OS has logged warnings/errors that could shed some light on what went wrong. Thanks! |
This comment has been minimized.
This comment has been minimized.
@kodejack thanks for the logs! First quick look there's nothing in or out process that clearly explain why the process has not launched inside the 20 seconds limit. @dalexsoto did mention to me that loaded libraries are
|
sorry I mean @mlancione above. Looking again at the forum post ot seems to affect only newer phones, i.e. those with |
We have posted an issue to Apple as well, I'll pass on the comment about arm64e. I'll get logs from the device directly. |
@spouliot and @kodejack - Same issue with us, and same information recorded in the crash dump about arm64 / arm64e architecture:
|
@mlancione unfortunately, we tried the "Offload App" workflow that you suggested, and this didn't fix the issue. Our app still crashes. |
@stewart-rae thanks for confirming! Multiple, consistent reports are helpful, otherwise we might end up investigating the wrong things :-) |
@spouliot Not sure if it helps: I'm working at Microsoft and have 2 customer apps affected by this. In both cases the apps are built by Microsoft. So it is easy to give you access to the full apps and source code internally. None of the apps are using a MDM SDK. |
Tried the "Offload App" workflow too did not seem to fix this issue. I have attached the crash log for the App @kodejack and I are working on: I have redacted the app name and bundle id with REDACTED.APP.NAME and REDACTED.BUNDLE.ID if you want to search the log. Here are some more details for the app:
|
This comment has been minimized.
This comment has been minimized.
I was able to test the deployed build from TestFlight not going through MDM and it doesnt crash on startup, it would appear that something in MDM is causing it to hit the time limit on start up? I thought it might be a combination of MDM, loading a config and other startup tasks which is causing the issue but an iPhone 6S Plus, which I would assume would take longer to start up the app, does not crash... Just to note this issue doesnt happen on: This is all very speculative but it would appear that the issue is pointing towards MDM and the arm64e CPU devices? |
This comment has been minimized.
This comment has been minimized.
Link to issue reported on Apple's dev forums: |
Everyone Please file a feedback ticket with Apple with your specific information. Also make sure to link this https://feedbackassistant.apple.com/feedback/8895585 ticket (in the text) so they can all be seen as a single issue. Thanks! |
@spouliot : We had raised a ticket with Apple's Developer Technical Support and shared all this info. This is the reply from Apple's DTS engineer : Us:
Apple's reply We shared these logs :
Apple's reply : First, it does look like you are using xamarin here, "xamarin_release_block_on_main_thread," if I am correct I should let you know that DTS does not support Xamarin and this is something you would have to contact the vendor about. |
Our App and many users are impacted by this issue. Is there any solution to this ? |
Hi! We are wondering the same as above. Thousands of users can be affected. Is the rootcause found? We follow this thread for updates :) |
Similar issues on iOS 14.2 here as well. We have customers with MDM deployments and most have a similar issue: The app hangs during startup and closes after 15 seconds (which implies the OS kills the app due to the 15 second startup limit). The logs indicate a hang on So far the MDM environments where this issue occurs are: The issue can seemingly occur on multiple kinds of iOS devices (we have received reports from customers running into issues on the Running our app in these MDM environments on iOS 14.1 (and earlier) still works as expected. |
@leonluc-dev so far you are the only one reporting this issue happening on earlier |
From this Apple forum thread it appears that NativeScript apps may also be experiencing this issue: This NativeScript thread describes a similar iOS 14 issue (but not specifically iOS 14.2): In that thread it is pointed out that the Apple iOS 14 Release Notes has this "Third Party App" Known Issues warning (https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-14-release-notes):
Is this at all relevant to our issue? |
@spouliot Apologies. It seems the iPhone 7 report was a report mixup. So far we've been able to confirm the issue at customers using the 2nd gen iPhone SE, iPhone XR or iPhone 11 (all of them ARM64e devices) |
@mlancione that's recent but not new in 14.2. AFAIK this should not be an issue but we'll be double-checking this. Thanks! |
We are seeing this issue with the following MDMs as well:
|
We are seeing this issue on an AirWatch MDM deployed xamarin app to an iPhone XR running iOS 14.2. Our app works fine when not deployed via AirWatch MDM (downloaded straight from app store). Our app works fine when deployed via AirWatch MDM to iphone XR running iOS 14.1 and below. |
Same problem here and this is very critical for us (we are using Intune as MDM) |
Yeah, you need to test your app and if it crashes look at the crash output
to see which trampoline was exhausted and then increment that specific
trampoline type. The numbers from some other app won't help yours because
each app will use different amounts of trampolines.
…On Fri, Jan 8, 2021 at 9:03 AM leonluc-dev ***@***.***> wrote:
@pranavtiwa <https://github.com/pranavtiwa> It depends on what errors you
are getting. You can read what values to change based on the errors at the
end of this post #10086 (comment)
<#10086 (comment)>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10086 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALXVAJKIMP25EB24UTM43LSY4NFLANCNFSM4TSLR3KA>
.
|
@jpeters5392 @leonluc-dev Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d Thread 0 name: tid_407 Dispatch queue: com.apple.main-thread This is the crash log but i couldn't find anything related to exhausted trampolines |
That looks like the crash log from the original MDM issue and not a crash
log from an app that was built with the trampoline workaround. You need to
build your app with the mtouch arguments that were supplied in this Github
issue as the workaround and then test that app without submitting to Apple
to ensure that if you execute all code paths it does not crash again. If
it does crash, then look at the crash logs since that will refer to a
specific trampoline type that you need to change.
…On Fri, Jan 8, 2021 at 2:22 PM pranavtiwa ***@***.***> wrote:
@jpeters5392 <https://github.com/jpeters5392> @leonluc-dev
<https://github.com/leonluc-dev>
Exception Type: EXC_BAD_ACCESS (SIGKILL)
Exception Subtype: UNKNOWN_0x32 at 0x00000001082f87e8
VM Region Info: 0x1082f87e8 is in 0x1082f8000-0x1082fc000; bytes after
start: 2024 bytes before end: 14359
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
VM_ALLOCATE 1082f4000-1082f8000 [ 16K] rw-/rwx SM=PRV
---> mapped file 1082f8000-1082fc000 [ 16K] r-x/r-x SM=COW ...t_id=3cc629b7
VM_ALLOCATE 1082fc000-108300000 [ 16K] rw-/rwx SM=PRV
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10
code:0x8BADF00D explanation:process-launch watchdog transgression:
application<***>:1346 exhausted real (wall clock) time allowance of 20.00
seconds | ProcessVisibility: Foreground | ProcessState: Running |
WatchdogEvent: process-launch | WatchdogVisibility: Foreground |
WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 23.430 (user
23.430, system 0.000), 20% CPU", | "Elapsed application CPU time (seconds):
19.877, 17% CPU" | ) reportType:CrashLog
maxTerminationResistance:Interactive>
Triggered by Thread: 0
Thread 0 name: tid_407 Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 ??? 0x00000001082f87e8 0 + 4432300008
This is . the crash log . Where i couldn't find anything related to
exhausted trampolines
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10086 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALXVAINPEVHGU5ABPKDJALSY5SQXANCNFSM4TSLR3KA>
.
|
STATUS ON THIS ISSUE? ANYONE? :-)
|
We are trying to configure trampoline count to 8K instead of suggested 4K. Getting the following error.
Any thoughts?
AOTID 7B01D48F-8CA2-BEE1-F139-A2B67804277A
* Assertion at /Users/builder/jenkins/workspace/archive-mono/2020-02/ios/release/mono/mini/aot-compiler.c:11160, condition `table_size < 65000' not met
MTOUCH : error MT3001: Could not AOT the assembly
Thanks
… On Jan 8, 2021, at 2:55 PM, jpeters5392 ***@***.***> wrote:
That looks like the crash log from the original MDM issue and not a crash
log from an app that was built with the trampoline workaround. You need to
build your app with the mtouch arguments that were supplied in this Github
issue as the workaround and then test that app without submitting to Apple
to ensure that if you execute all code paths it does not crash again. If
it does crash, then look at the crash logs since that will refer to a
specific trampoline type that you need to change.
On Fri, Jan 8, 2021 at 2:22 PM pranavtiwa ***@***.***> wrote:
> @jpeters5392 <https://github.com/jpeters5392> @leonluc-dev
> <https://github.com/leonluc-dev>
> Exception Type: EXC_BAD_ACCESS (SIGKILL)
> Exception Subtype: UNKNOWN_0x32 at 0x00000001082f87e8
> VM Region Info: 0x1082f87e8 is in 0x1082f8000-0x1082fc000; bytes after
> start: 2024 bytes before end: 14359
> REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
> VM_ALLOCATE 1082f4000-1082f8000 [ 16K] rw-/rwx SM=PRV
> ---> mapped file 1082f8000-1082fc000 [ 16K] r-x/r-x SM=COW ...t_id=3cc629b7
> VM_ALLOCATE 1082fc000-108300000 [ 16K] rw-/rwx SM=PRV
>
> Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
> Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10
> code:0x8BADF00D explanation:process-launch watchdog transgression:
> application<***>:1346 exhausted real (wall clock) time allowance of 20.00
> seconds | ProcessVisibility: Foreground | ProcessState: Running |
> WatchdogEvent: process-launch | WatchdogVisibility: Foreground |
> WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 23.430 (user
> 23.430, system 0.000), 20% CPU", | "Elapsed application CPU time (seconds):
> 19.877, 17% CPU" | ) reportType:CrashLog
> maxTerminationResistance:Interactive>
> Triggered by Thread: 0
>
> Thread 0 name: tid_407 Dispatch queue: com.apple.main-thread
> Thread 0 Crashed:
> 0 ??? 0x00000001082f87e8 0 + 4432300008
>
> This is . the crash log . Where i couldn't find anything related to
> exhausted trampolines
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#10086 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALXVAINPEVHGU5ABPKDJALSY5SQXANCNFSM4TSLR3KA>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@sankar12345 there are several type of trampolines. Please tell us every option being provided to the Additional mtouch arguments |
Thank you.
This is the option we are trying to give ( 8192 is causing problem . When it is 4096, there’s no issue)
aot=nopagetrampolines,ntrampolines=40960,nrgctx-trampolines=40960,nrgctx-fetch-trampolines=8192,ngsharedvt-trampolines=8192,nimt-trampolines=8192
Thanks
… On Jan 12, 2021, at 11:55 AM, Sebastien Pouliot ***@***.***> wrote:
@sankar12345 there are several type of trampolines. Please tell us every option being provided to the Additional mtouch arguments
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
DOES iOS 14.3 solve the MDM issues?An iOS update is ready now - the 14.3.. Did anyone have the chance to test if this one solves any issues? |
@AlfDoej For us 14.3 did not solve the MDM issues. The trampoline workaround described earlier still works though. |
Bug seems to have been fixed in iOS 14.4 Beta 2. Can anyone confirm please? |
Yes, I can confirm. |
@sankar12345 nrgctx-fetch-trampolines=4096 should be enough, why did you have to double it, was there a failure without it ? |
We have not heard back from Apple but I can confirm too that a "known to be broken" app works fine with 14.4 beta 2. |
Thank you.
There was no failure, but we were reaching almost to 200 trampolines at run time across our 3 + day continuous run of the app .
As We continue to test more, we wanted to explore if setting a much higher number will alleviate even the slightest of possibility of a crash when released.
Thanks
… On Jan 13, 2021, at 1:35 PM, Zoltan Varga ***@***.***> wrote:
@sankar12345 nrgctx-fetch-trampolines=4096 should be enough, why did you have to double it, was there a failure without it ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I got in touch with Apple DTS and they confirmed me that the new iOS 14.4 beta 2 beta does have the fix we were waiting for. This means the workaround won't be needed once customers upgrade to the final, public release of iOS 14.4. Sadly this also means that the workaround is required as long as you wish to support MSM deployment on iOS 14.2 and 14.3. We'll continue to test each new beta until a public/stable iOS release ships with the fix. |
@spouliot any timeline for release of 14.4 ..?? |
@pranavtiw no, that's iOS (not Xamarin) so you'll need to ask Apple for timelines :-) You can try to guesstimate a date using https://xcodereleases.com - but, so far, there's not Xcode associated with iOS 14.4. There's a rumour of an event in March. New version of iOS are often required when releasing new hardware model... but neither the event nor the required update are certainties. |
If Apple fixes this in 14.4 (Public Release), do the users need to update their devices to 14.4 OS or we need to build the application with the latest XCode(comes with iOS 14.4) and then redeploy it to MDM servers? |
I just tested iOS 14.4 RC (release candidate) and it works fine. @udayvalluri existing "broken" applications works fine with iOS 14.4. This means the only requirement will be for your users to update to iOS 14.4. If you used the workaround then you might want to remove it - now or later. Be aware that removing it will break MDM-users running iOS 14.2 and 14.3. |
Working on iOS 14.4 public release that I just downloaded from official OTA update... |
Thanks for all the info and updates. It's greatly appreciated. I can verify as well that applying iOS 14.4 RC resolves the issue for our customers. |
Just here confirming this also fixed NativeScript apps as well. Let's all have a party |
The final iOS 14.4 version is the same as the release candidate. To avoid any doubt I updated a different phone to make my last checks - and it worked like expected. A huge thank you to everyone who reported the issues, both to us and Apple. Additional ❤️ for everyone who provided additional informations, crash logs, time and who helped others. |
Hi
Can somebody help to describe technical details of trampoline and how that’s used .
I know at a high level, but would love to get some more details on how it internally is used..
I know 14.4 has put an end to this discussion, but could use some additional details on trampoline technical details
Thanks
… On Jan 26, 2021, at 5:14 PM, Sebastien Pouliot ***@***.***> wrote:
The final iOS 14.4 version is the same as the release candidate. To avoid any doubt I updated a different phone to make my last checks - and it worked like expected.
A huge thank you to everyone who reported the issues, both to us and Apple. Additional ❤️ for everyone who provided additional informations, crash logs, time and who helped others.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi, --Error Logs-- |
I'm not seeing an issue with iOS 14.5.1. I've tested an AppStore app that contains the trampolines workaround that is deployed via MDM to an arm64e iPad and it seems to be working fine. Has anyone else seen issues yet? |
Hi, error 15:16:14.606730+0200 duetexpertd Failed to create new framestore with nil filename Thanks in Advance, |
Did you ever find out why this was specific to MDM? I'm facing a kind of similar issue with my private app, not related to Xamarin, but also the crash we are seeing only happens on iOS 14 (not 15). After analyzing a lot of logs and stack traces I suspect it may be a trampolines-related bug, but what I don't understand is, why MDM? What is different about an MDM install? Any insights you could offer would be super-appreciated. Thanks! |
🚨⚠️ 🚨⚠️ 🚨⚠️ 🚨⚠️
See current proposed solution
🚨⚠️ 🚨⚠️ 🚨⚠️ 🚨⚠️
Steps to Reproduce
https://forums.xamarin.com/discussion/186138/ios-14-2-app-crashes-if-deployed-via-mdm-but-not-from-appstore
Expected Behavior
The App shout start normally
Actual Behavior
The app crashes on start as it takes to long to start.
Environment
iOS 14.2 built with Mac OS 10.15.
https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md
Symbolicated StackTrace
Crash Report
Incident Identifier: 7A338BC3-9B9D-45BA-8367-6D2C7DB38D54
CrashReporter Key: 0a7f5514b1eabef9a9ced769aec120d56c1212d7
Hardware Model: iPhone12,1
Process: REDACTED.Mobile.iOS [441]
Path: /private/var/containers/Bundle/Application/ACDDB724-517E-4FC1-B07E-DEAEE9FE213A/REDACTED.Mobile.iOS.app/REDACTED.Mobile.iOS
Identifier: REDACTED
Version: 2011041216 (1.0.1)
AppStoreTools: 12A7604b
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: REDACTED [411]
Date/Time: 2020-11-09 14:53:13.4760 +0000
Launch Time: 2020-11-09 14:52:53.4304 +0000
OS Version: iPhone OS 14.2 (18B92)
Release Type: User
Baseband Version: 2.02.04
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGKILL)
Exception Subtype: UNKNOWN_0x32 at 0x0000000105c908a8
VM Region Info: 0x105c908a8 is in 0x105c90000-0x105c94000; bytes after start: 2216 bytes before end: 14167
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
VM_ALLOCATE 105c8c000-105c90000 [ 16K] rw-/rwx SM=PRV
---> mapped file 105c90000-105c94000 [ 16K] r-x/r-x SM=COW ...t_id=5d9c747d
VM_ALLOCATE 105c94000-105c98000 [ 16K] rw-/rwx SM=PRV
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:process-launch watchdog transgression: application:441 exhausted real (wall clock) time allowance of 20.00 seconds | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: process-launch | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 29.110 (user 29.110, system 0.000), 24% CPU", | "Elapsed application CPU time (seconds): 19.906, 17% CPU" | ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0
The text was updated successfully, but these errors were encountered: