Summary
Since the last update of our app was released, many users started complaining about the app not starting anymore. We received a crash log and console log from 2 different users, as well as a video from the crash.
Our app does not crash on every device, but when it does it crashes every single time within a second of tapping the icon (the video shows this as well as the phone of a friend).
The crash log is very weird, for it does not contain a backtrace and the frame pointer (R7) is 0x00000000. We didn't change much for this update and nothing we changed could corrupt the stack like this. Furthermore, reinstalling the app fixes the issue. This leads us to believe the error is not in our code, but in the binary which might have become corrupted somewhere.
Details
According to some users our app crashes on startup since the last update. We are unable to reproduce this issue but received crash logs from one the users. The log comes from the harddrive of the user (~/Library/Logs/CrashReporter/MobileDevice/). I've seen the same thing directly from the phone of a friend who experiences the same issue.
This crash appears to occur as soon as our app receives control from iOS (see update). However, the crash logs contains no backtrace and states an error occurred on an unknown thread. I tried symbolicating the log, but obviously there is nothing to symbolicate.
It appears to be some kind of nullpointer error, but why no backtrace? What could cause this type of error and what can I do to reproduce/solve it?
Incident Identifier: 984C8208-F4B4-4325-90B3-C9BE371E1A12
CrashReporter Key: c512972e5cd00e75d8d7a6ddb59ff9a08946fd7b
Hardware Model: iPad3,3
Process: MyApp [3224]
Path: /var/mobile/Applications/A0AEAA1D-7E5D-4BDC-8C9F-EA5FF4595059/MyApp.app/MyApp
Identifier: MyApp
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-10-18 09:27:06.158 +0200
OS Version: iOS 6.0 (10A403)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000
Highlighted Thread: 0
Backtrace not available
Unknown thread crashed with ARM Thread State (32-bit):
r0: 0x000e64e0 r1: 0x7f8940c0 r2: 0x00000000 r3: 0x3c56cb88
r4: 0x2fd1bd34 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000
r8: 0x2fd1bd3c r9: 0x3c5688a8 r10: 0x00000000 r11: 0x00000000
ip: 0x80000028 sp: 0x2fd1bd40 lr: 0x2fe9a8d7 pc: 0x000e64e0
cpsr: 0x60000010
Binary Images:
0xe5000 - 0x170fff +MyApp armv7 <15fd2c3131d03790bcd321411a241390> /var/mobile/Applications/A0AEAA1D-7E5D-4BDC-8C9F-EA5FF4595059/MyApp.app/MyApp
0x2fe96000 - 0x2feb6fff dyld armv7 <75594988728831d98e1f7c4c7b7ca29d> /usr/lib/dyld
[...]
Update
A video sent to me by the same user indicates the app crashes even before the intro animation starts. So before the app is actually running (or one of the first lines of code our app runs).
In ARMv6/7 architecture, the R7 register holds the frame pointer. It should point to the previous stack frame, but is 0x00000000 in our case. A lot of registers are null actually. What could possibly cause this?
Also, the crashing is very consistent; it crashes every time within a second of tapping the icon. At least for this particular user. We've had more, but less specific, reports of the app "not starting". Re-installing the app fixes any problem the user had.
The console log doesn't show much either, just this:
It's starting to sound very much like updating through the App Store corrupts the binary, but only on updating:
http://www.pcworld.com/article/258827/updated_apps_crashing_heres_what_you_need_to_know.html
http://www.marco.org/2012/07/04/app-store-corrupt-binaries
I've sent a request to Apple's technical service to help out on this. I'll report back here.
Apple Technical Service update
I've posted a bug report, they requested a console log of the time of crash. I've supplied them one, which to my understanding doesn't contain much of use. Except:
2012-10-23 09:14:18 +0000 backboardd Application 'UIKitApplication:com.company.myapp[0xdd31]' exited abnormally with signal 11: Segmentation fault: 11
The technical department doesn't know what to do about this issue either, but advised us NOT to upload a new binary without any code changes. There is no way to test if the issues goes away (wtf) and if it doesn't work it will upset users even more.
Still waiting for the answer to my bug report...
After contacting Apple Tech Support we were asked to file a bug report describing this issue. We've uploaded the crash report, console log, the archive from Xcode of this version and the IPA file (App Store file) of this version from iTunes.
After waiting for about a week we received the following email from Tech Support today:
Hello,
I wanted to let you know that a fix is in place for the issue that was
causing crashes for customers who installed updates to your app.
Customers who were experiencing crashes after installing an update can
fix the problem by updating the app again in the App Store. This will
install a fixed version of the app.
An update to your app should appear in the App Store. Updating will
re-install the current version of the app, and fix any crashes related
to bad installs. All of the app's saved data will be unaffected by the
update.
Please let me know if you are not seeing an update for your app, or
are still seeing crashes after installing the update.
If you have concerns about any reviews your app received as a result
of this issue, please contact the the store team directly at
http://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wa/jumpTo?page=contactUs&contactfaq=customerreviewremovalrequest
and reference ticket number [my number].
We checked with a friend who had the crashing version of the app installed. He confirmed he downloaded the update and this fixed the issue. The update Apple created does not show up in iTunes Connect so far, but it obviously works.
I'm pleased with the service Apple provided. Things do occasionally go wrong I guess, even the Apple gods make mistakes. Too bad our users aren't always that forgiving (though the majority is). It seems Apple even removed all the 1 star reviews for us, without asking. We can't check it at the moment, because AppFigures is currently down due to hurricane Sandy...
Related
I have an app that is running with React-Native that doesn't crash on react-native run-ios, neither when I run it on Xcode, but when I upload it to iTunes Connect, the build is refused because of a crash.
The problem is that I cannot see the crash on Xcode > Window > Organizer > Crashes, because I cannot make it crash with a device or a simulator.
Does somebody know how to import a crash that comes from iTunes Connect to Xcode ?
Here is my crash log :
{"app_name":"mdef","timestamp":"2017-12-11 11:40:02.33 -0800","app_version":"1.2.0","slice_uuid":"3ff1d45d-3b65-325e-8df9-5b0ccf7550b7","adam_id":1246228626,"build_version":"66","bundleID":"com.mdef.mymatchup","share_with_app_devs":false,"is_first_party":false,"bug_type":"109","os_version":"iPhone OS 11.2 (15C114)","incident_id":"A6BCA3E0-DBB1-4E24-82F1-7B418F023CB0","name":"mdef"}
Incident Identifier: A6BCA3E0-DBB1-4E24-82F1-7B418F023CB0
CrashReporter Key: 972854c2d639e93f8277daa382921f72f9e8d379
Hardware Model: xxx1
Process: mdef [12142]
Path: /private/var/containers/Bundle/Application/07E05B5A-9B60-4A2E-BE1B-895E72344FC5/mdef.app/mdef
Identifier: com.mdef.mymatchup
Version: 66 (1.2.0)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.mdef.mymatchup [5622]
Date/Time: 2017-12-11 11:40:02.1820 -0800
Launch Time: 2017-12-11 11:40:01.1784 -0800
OS Version: iPhone OS 11.2 (15C114)
Baseband Version: n/a
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 1
Application Specific Information:
abort() called
Filtered syslog:
None found
Last Exception Backtrace:
(0x185cbe364 0x184f04528 0x185cbe2ac 0x104a8ff40 0x104a8dc04 0x185cc5cd0 0x185ba456c 0x185ba901c 0x104aa10b8 0x104ae0dd8 0x104ae0b38 0x18563aa54 0x18563aa14 0x18564496c 0x1856452fc 0x185645d20 0x18564e03c 0x1858e2f1c 0x1858e2b6c)
First of all in organiser crash logs will imported automatically if there will be any crash occurs on live app version.
Here you mentioned that your uploaded binary rejected due to crash issue. So they have provided you crash logs. Now that crash logs will not be imported into Xcode because App is not live yet.
So my suggestion is to resolve crash issue using this crash logs & lets get approval of application & make it live on app store. So after that if any user gets crash issue you will get list of it on Xcode -> Organiser.
Edit :
If you are not able to find out or detect the crash log than you should ask apple review team to provide more details regarding that crash issue
They can provide device & OS details to regenerate the crash also they can provide you steps to reproduce the crash.
If everything works than you should try & re upload new binary. You will surely get approval after this ways
For more better crash issues with detailed analysis you can use this crashlytics tool : https://fabric.io/kits/ios/crashlytics
Hope it will help you.
Thanks...
You can use analytic tools like fabric Crashlytics. whenever your app crashes on any device, Crashlytics will give you a detailed report about the crash on the dashboard with exact line number and details of the user's device.
Read this blog written by Bruno Barbieri about integrating Crashlytics in your react native app.
Or you can see crash manually from Xcode organizer.
read this to know more about checking crash reports from Xcode.
Solved ! I have fixed my problem by downgrading React-Native from 0.51.0 to 0.49.5, and I have no more crashes.
I was running an app on Xcode with the iPhone 6 stimulator using the latest iOS 10. And after some time the app crashed with the following message:
debugserver died with an exit status of 0x00000000
Here is the screenshot of that crash message:
I ran the code at 7:56 PM and it crashed 9 minutes later. So does anyone have any idea why this is happening? Is this an indication that the app might crash when it goes to the background or anything else?
To give you further insides of it why it happens there are several reasons:
The debugserver crashed or was terminated by another process
More likely the debugserver had a memory or CPU usage peak which invoked termination.
To fix this, update your version and see for updates or wait for next patches, releases from apple.
Also check for specific processes that use up a lot memory or CPU usage below (e.g. Chrome / Firefox) terminate them and observe it happen more frequent or not at all anymore.
I think that's all what you can do on YOUR side. I hope that brings a bit more clarity where the problem lies.
I recently started testing my iPhone app on my iPhone 5S device directly from XCode 5's debugger, and it seems to randomly crash the entire phone. I cannot pinpoint what the exact issue is. I'm not doing anything at all in my AppDelegate, so I don't believe it's related to something on load time. Sometimes performing a delete of the application, then a reset of the phone, and then a clearing of XCode's entire cache temporarily fixes the problem, but then it spontaneously comes back. It's very inconsistent. I'm at a complete loss at this point. The latest crash finally showed the following error message on the device itself:
Incident Identifier: 4180F1E2-E932-417A-92BE-82F2C414FB82
CrashReporter Key: e3cdd62843930ef2e7bcffbdb79479abc6141800 Hardware
Model: iPhone6,1 Process: XcodeDeviceMonitor [230]
Path: /Developer/usr/bin/XcodeDeviceMonitor Identifier:
XcodeDeviceMonitor Version: ??? Code Type: ARM
(Native) Parent Process: launchd [1]
Date/Time: 2013-11-09 18:54:39.040 -0500 OS Version:
iOS 7.0.3 (11B511) Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes:
0x0000000000000001, 0x00000000e7ffdefe Triggered by Thread: 0
Dyld Error Message: Library not loaded: /usr/lib/liblockdown.dylib
Referenced from: /Developer/usr/bin/XcodeDeviceMonitor Reason: image
not found Dyld Version: 324
Binary Images: 0x2befb000 - 0x2bf1efff dyld armv7s
/usr/lib/dyld
Given the reference to a breakpoint in the crash log, I do have one idea. In the past, I have seen Xcode crash my apps on launch if breakpoints are enabled. Try disabling breakpoints before launching the app, then enabling them shortly after launch, if you are using any. Let me know if this seems to make any sort of consistent difference!
It looks like the latest version of Xcode (5.0.2) that was released this past week resolved my issue. At least I haven't seen it since I applied the patch. I noticed one of the major issues fixed was for the debugger crashing the phone on iOS 6, but I suspect whatever they did also fixed my similar issue for iOS 7. Anyway, it's acting much more consistent now. Thanks for everyone's help.
One of our apps recently got rejected for the second time, because "We found that your app failed to launch on iPad running iOS 6.0.1, on both Wi-Fi and cellular networks".
The crash log provided by Apple starts with:
Incident Identifier: CE8868A8-1C68-4161-91AD-DB50D3D5780B
CrashReporter Key: 83b816533ead866666681b87f5736242d8aac2ff
Hardware Model: xxx
Process: Test Skis [29192]
Path: /var/mobile/Applications/890E8D9C-6A17-4EA6-9A06-5503B3D35888/Test Skis.app/Test Skis
Identifier: Test Skis
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2013-01-04 19:24:52.667 -0800
OS Version: iOS 6.0.1 (10A523)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
My question is not about how to fix the problem in our specific code, but a more general one: we have been unable to reproduce the crash using the same binary (making an Ad Hoc version), device, and OS version as the one Apple is supposedly using.
How is it possible that such a crash occurs on the Apple reviewer's device, and not ours? Are Apple reviewers' devices configured in a non standard way that could explain the difference?
I have found another question on Stack Overflow mentioning a similar issue, which has not been answered as well: Apple rejected app due to a crash which is not reproducing
My guess would be your ad-hoc build configuration is not identical to your release/distribution configuration in some way.
I had the same problem, and Apple sent me a crash report to look at. I learnt how to symbolicate them, but the relevant lines of code in my app would not symbolicate. So I tried making some other changes and resubmitted, resulting in the same rejection.
Finally I requested them to send more details because I tested with two devices and on the simulator. And today I saw that they 'Developer removed from sale' and then 'Ready for sale'. So I guess my app is good to go, without any change from my side.
It looks like you are trying to instantiate a nib (name unknown, since the exception reason is missing in the crash report) and it isn't present. Make sure all nibs required by the app are actually part of the build you send to Apple.
I have an iPad app out in the field (enterprise distribution) that randomly stopped working (after about 150 uses). It loads the black screen like its about to open but then flashes back to the main screen.
No other apps are installed on the iPad.
iPad is not jailbroken.
iPad software has not been updated since install.
The app remains in the running list, but will not open. After resetting the iPad and reinstalling the app, it runs fine again. The crash report is as follows:
Incident Identifier: 97E6C3AC-0A3F-4D5A-9316-14361B8875C8
CrashReporter Key: acbe2088ab1236c4f317ec9e0fb85d4a9d7b5b3a
Hardware Model: iPad1,1
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-08-05 14:52:54.380 -0400
OS Version: iPhone OS 4.3.2 (8H7)
Report Version: 104
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 dyld 0x2fe0124a dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*) + 446
1 dyld 0x2fe01058 _dyld_start + 48
Thread 0 crashed with ARM Thread State:
r0: 0x00000000 r1: 0x00000009 r2: 0x00000009 r3: 0x0004a000
r4: 0x0004a01c r5: 0x00000000 r6: 0x00000005 r7: 0x2fe48a18
r8: 0x2fe6f18c r9: 0x2fe96964 r10: 0x2fe494f4 r11: 0x00049000
ip: 0x2fe96984 sp: 0x2fe489d0 lr: 0x2fe489ac pc: 0x2fe4a24a
cpsr: 0x60000030
Binary Images:
0x2fe49000 - 0x2fe6efff dyld armv7 <bb9bfc7d242331d29a79adf7ef7aaa18> /usr/lib/dyld
This is all the information the report contains.
We've never been able to reproduce the crash on the simulator.
Any ideas? Can't send this back out until we make sure the error is fixed. Thanks,
The system is probably killing the app because the provisioning profile has expired. If you can get access to the old app (e.g. by syncing with iTunes and then doing Reveal in Finder on the app) then you can find the provisioning profile inside the app as embedded.mobileprovision which you can inspect to determine if it has expired.
Check your startup sequence carefully. Perhaps some config file you are reading is corrupt or cannot be deserialized to a data structure (e.g., NSDictionary) properly.
I've had this happen to me.
I came across this issue today and finally I adjust the provisioning profile of my app then the strange crash disappeared.
So you can try to this method to solve the problem.
PS:My crash log is same as the JJ's
Good luck.
1.make sure the device identifier key has been added in your IDP's distribution profile,
2.download that profile and drop on to Xcode
3.clean, build/archive you app project
4.Give users a URL to download(install) that mobileprofile file
5.enterprise distribution you app.
Try to add to your project setting not just armv7 but armv6 also.
Does it occur always after 150 or more uses?
If yes then checkout what all parameters get affected when it's used for large number of time.
I had faced similar problem but my app was using core data.I was saving some value and by mistake I had set the type to INT 16. and it used to crash whenever value passes 2^15 for ios 5 and above.
Secondly , are you able to re-start app after quitting the app from background or you have to delete the app and re-install it to fix the problem?