Our app crash on os 10.3.3 10.3.4, iPhone 5c /5 iPad4 (armv7s 32) compiled by Xcode 11.4, swift optimization on. We find the PC register point to a hole address without virtual address and no stack information. If we close swift optimization, it works.
So do anyone find the problem and any solution?
It's certain that it's related to Xcode 11.4 swift optimization.
I find the same question here. https://www.reddit.com/r/iOSProgramming/comments/frcpsc/xcode_114_builds_crashes_on_ios_10/
Incident Identifier: 2224949E-E5E3-479C-9B08-4FD1473144B3
CrashReporter Key: 052c9a28855da965790a6dcc0885097a66ee4eff
Hardware Model: iPad3,4
Process: AAAAA [34872]
Path: /private/var/containers/Bundle/Application/xxxxxx....
Identifier: com.xxx.xxxxx
Version: xxxx
Code Type: ARM (Native)
Role: Non UI
Parent Process: launchd [1]
Coalition: com.xxx.xxxxx [1932]
Date/Time: 2020-03-30 22:42:49.2564 +xxx
Launch Time: 2020-03-30 22:42:47.0000 +xxx
OS Version: iPhone OS 10.3.3 (14G60)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: KERN_PROTECTION_FAILURE at 0x015fa500
Triggered by Thread: 0
Thread 0 name:
Thread 0 Crashed:
0 ??? 0x015fa500 0 + 23045376
After lots of analysis such as log and instruction debug, I am surely it's a bug xcode 11.4 swift compiler optimization.
Detailedly, the optimization cause a stack pointer (fp) messy at the point opening a new function stack frame.
I show it in the following.
Here is a helper function type metadata accessor for myapp.MainViewController at <compiler-generated> generated by compiler in our mainviewcontroller.
<+0>, <+4> is wrong. It should be
0x6cd85c <+0>: push.w {r4, r5, r6, r7, lr}
0x6cd860 <+4>: add r7, sp, #0xc
r7 is fp. so the error instruction <+0> don`t save r7, and <+4> sub ins makes r7 lower than sp a lot that causes all whole stack messy. So It's wrong clearly.
This is what happens when the ins execute.
Before:
After:
The whole stack loses becuase of fp error.
And we can also verify that in xcode 11.3.
<+0> <+2> is the same as our expectation above.
So we have to downgrade to xcode 11.3 as well and use runtime refection to adapt new iOS SDK feature that should be call in xcode 11.4.
We have also encountered multiple crashed on old 32-Bit devices with iOS 9 or 10. Recompiling with Xcode 11.3.1 fixed those random crashes in my case...
There is also a open Bug for this topic at https://bugs.swift.org/browse/SR-12511
This is fixed for us in Xcode 11.5.
GM_Seed which is available since May 18.
https://developer.apple.com/services-account/download?path=/Developer_Tools/Xcode_11.5_GM_Seed/Xcode_11.5_GM_Seed.xip
Related
I have a weird problem since a few days. After exporting a project for android once it works fine the 2nd export I do eclipse crashes with this error:
Identifier: org.eclipse.eclipse
Version: 3.8 (3.8)
Code Type: X86-64 (Native)
Parent Process: launchd [269]
Date/Time: 2013-03-12 21:36:13.365 +0100
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6
Interval Since Last Report: 321292 sec
Crashes Since Last Report: 3
Per-App Interval Since Last Report: 44806 sec
Per-App Crashes Since Last Report: 2
Anonymous UUID: 52A136CA-CDAE-4661-B166-51B04A18C21C
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x000000000000000a, 0x000000011f1c965f
Crashed Thread: 46 Java: ModalContext
Any clues. Running: adt-bundle-mac-x86_64-20130219
SIGBUS looks like bad RAM but then other things would act up aswell?
B
I guess that's random. As mentioned in this thread it looks like it can happen if eclipse is building your project at the same time as you're exporting it. You could try to disable the "build automatically" option in eclipse while you're exporting it.
I'm sorry if this question was somewhere here already, but I'm struggling with this problem for hours with no results. Long story short - I have a fresh installation of Xcode (version 3.2.5 64bit) and when I try to run my app with a performance tool (let's say Leaks), Instruments just crash, no matter which tool I choose. As I'm a beginner when it comes to Xcode I have no clue what's wrong. Please find the crash report below:
Process: Instruments [4033]
Path:
/Developer/Applications/Instruments.app/Contents/MacOS/Instruments
Identifier: com.apple.Instruments
Version: 2.7 (3017) Build
Info: Instruments-30170000~6 Code
Type: X86-64 (Native) Parent
Process: launchd [172]
Date/Time: 2011-03-29
19:43:52.996 +0100 OS Version:
Mac OS X 10.6.7 (10J3250) Report
Version: 6
Interval Since Last Report:
118589 sec Crashes Since Last Report:
14 Per-App Interval Since Last Report:
24 sec Per-App Crashes Since Last
Report: 5 Anonymous UUID:
5934F52C-EF00-40F1-A0B4-17D52FA623F1
Exception Type: EXC_BREAKPOINT
(SIGTRAP) Exception Codes:
0x0000000000000002, 0x0000000000000000
Crashed Thread: 0 Dispatch queue:
com.apple.main-thread
Dyld Error Message: Symbol not
found:
_CSSymbolicatorCreateWithMachKernel Referenced from:
/Developer/Applications/Instruments.app/Contents/MacOS/../../../../Library/PrivateFrameworks//InstrumentsPlugIn.framework/Versions/A/InstrumentsPlugIn
Expected in:
/System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
Has anyone experienced something like this before or knows how to fix it? I hope I've formulated my problem descriptively enough. I'd appreciate your help!
Thanks!
After days of fruitless struggle I have just updated my Xcode to version 4 and everything works perfectly fine. I still have no idea what was wrong with my previous installation, but since my Instruments work now, I won't investigate in any longer.
I've been trying to re-upload a previously uploaded app (it originally failed submission), but both the 'Validate' and the 'Submit' button in Organiser crash Organiser itself before finishing. This has been happening for about three days now, and I haven't heard a word back from the iTunesConnect helpdesk. I am running the lastest Xcode 3.2.5 with iOS 4.2.1, and downloaded and installed the latest Application Tools as instructed. Everything installed fine.
I'm getting a:
with:
Process: Xcode [32144]
Path: /Developer/Applications/Xcode.app/Contents/MacOS/Xcode
Identifier: com.apple.Xcode
Version: 3.2.5 (1760)
Build Info: DevToolsIDE-17600000~5
Code Type: X86-64 (Native)
Parent Process: launchd [348]
Date/Time: 2010-12-03 17:29:50.499 +1000
OS Version: Mac OS X 10.6.5 (10H574)
Report Version: 6
Interval Since Last Report: 4332 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 1215 sec
Per-App Crashes Since Last Report: 2
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 7 Dispatch queue: com.apple.root.default-priority
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[ITunesSoftwareApplicationDescription applicationType]: unrecognized selector sent to instance 0x200c57ae0'
*** Call stack at first throw:
(
0 CoreFoundation 0x00007fff840087b4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x00007fff886ea0f3 objc_exception_throw + 45
2 CoreFoundation 0x00007fff84062110 +[NSObject(NSObject) doesNotRecognizeSelector:] + 0
3 CoreFoundation 0x00007fff83fda91f ___forwarding___ + 751
I know that this isn't the place to debug Apple apps - but someone must have had this happen and figured out how to get past it? I'm getting no joy from apple :(
thanks
As a work around, you could try Application Loader.app in /Developer/Applications/Utilities.
I generally find this more reliable.
You should create an .ipa file for you App and then use application loader as Andrew said.
Worked for me.
Btw nobody can get joy from a computer company ;) ... Apple or any other...
Check what version of Xcode you're running. I had a similar issue where I was running a developer preview - you can't submit an app from a DP version of Xcode, and mine was crashing at the exact same point as yours.
Hope this helps.
My iPhone app was recently rejected from the App Store "because it crashes on launch". However, I cannot reproduce this crash. The app works perfectly on both the simulator and a device with the same hardware and software Apple tested it on (iPhone 3.1 running iOS 4). The crash logs they sent me say "No Backtrace Available", so I have nowhere to look in my code. Here's an example:
Incident Identifier: [...]
CrashReporter Key: [...]
Hardware Model: iPhone3,1
Process: [MyApp] [1172]
Path: /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
Identifier: [MyApp]
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-07-08 [...]
OS Version: iPhone OS 4.0 (8A293)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648
Highlighted Thread: 0
Backtrace not available
Unknown thread crashed with ARM Thread State:
r0: 0x00002388 r1: 0x00000000 r2: 0x3e2b47c8 r3: 0x00000108
r4: 0x2fe00000 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000
r8: 0x2ffffb48 r9: 0x2fffecfc r10: 0x00000000 r11: 0x00000000
ip: 0x00000010 sp: 0x2ffffb4c lr: 0x2fe08907 pc: 0xfe42c648
cpsr: 0x40000010
Binary Images:
0x1000 - 0x78fff +[MyApp] armv7 <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
0x2fe00000 - 0x2fe26fff dyld armv7 <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld
[many more libraries...]
How can I begin debugging this? Is it possible this is a build issue rather than a coding bug? And can I extract any useful information from the "ARM Thread State" or the "Binary Images" portions of the crash report?
Thanks!
*update: * I have installed the app for the first time on another iPhone running iOS 4 and still cannot reproduce the crash. I'm beginning to think this is an issue with build-time parameters such as libraries or targeted versions. Based on the crash report, is it likely that any of my application's code was executed?
See Technical Note TN2151:Understanding and Analyzing iPhone OS Application Crash Reports. Symbolication would normally help you track down the source of a crash but since there is no backtrace it may not help in this instance.
Don't bother testing on the simulator. The simulator build and the device build are wholly separate compiles for two different pieces of hardware. Just because it runs on simulator tells you nothing about a failure on device.
Remember that Apple will stress test the app by doing things like launching it on iOS4 with other apps eating up most of the memory. You will need to do that as well on your test device.
You will most likely have to wipe your test device back to defaults to replicate the test Apple does. Then open every possible app before launching your own.
You can make some information from the ARM thread state. The PC register is the only one containing the invalid address that the crash report is complaining about. That means your app tried to execute code at that address.
SIGSEGV means that the address in question is invalid. The system has setup no memory pages with this address.
I don't think the iOS will allow you to simply execute code from any address, but it is possible that the stack frame was corrupted and the return address was invalid when a function returned. That supports the "backtrace not available" problem.
Fouling the stack may be a result of a buffer overrun. If you use memcpy or a loop of sets on a local variable array and overrun the end of the array, you can destroy the stack.
A segfault is unlikely to be a build error. To reproduce this problem, try clearing out any saved information on the iPhone simulator before running the project; it is possible that you are assuming the existence of certain entries in NSUserDefaults that are present on your own iPhone, but which would not be available on a default installation. If that doesn't reproduce the problem, then you should create unit tests for each of your components, ruling out each component at a time as the cause of failure. Eventually, you will have ruled out every cause of failure except for the true cause of failure.
I was never able to reproduce the crash. I messed with a few build params and resubmitted and it was approved.
I'm running Xcode 3.2.3 with the iOS 4.0 SDK. I built my app with Base SDK = iphoneos4.0, Active SDK = iphoneos4.0, Deployment Target = 3.1.3, and Architecture = standard (arm6 arm7). Compiler = GCC 4.2. As I understand it, this is the correct way to build an app for both iOS 4 and 3.
The app runs fine on devices running iOS 4. But it crashes on startup when you try to run it on a device with iOS 3.1.3 (an iPod Touch 1G):
dyld: Symbol not found: __NSConcreteStackBlock
Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Expected in: /usr/lib/libSystem.B.dylib
It appears to be an issue with a fairly "low level" dynamically-linked library, BEFORE my main() function even gets called. I have even tried re-starting the device, etc., with no luck. Here's part of the the crash log:
Process: MyApp [60]
Path: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Identifier: MyApp
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2010-07-22 17:16:17.942 -0400
OS Version: iPhone OS 3.1.3 (7E18)
Report Version: 104
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x00000001, 0xe7ffdefe
Crashed Thread: 0
Dyld Error Message:
Symbol not found: __NSConcreteStackBlock
Referenced from: /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
Expected in: /usr/lib/libSystem.B.dylib
Dyld Version: 149
Binary Images:
0x1000 - 0x80fff +MyApp armv6 <d5f0ff6f233b4b034c222c16438c88d9> /var/mobile/Applications/192B30ED-16AC-431E-B0E9-67C1F41FD5DA/MyApp.app/MyApp
0x2fe00000 - 0x2fe26fff dyld armv6 <544395a4b5546114b878d5131a84fd7f> /usr/lib/dyld
0x30410000 - 0x30536fff libSystem.B.dylib armv6 <0373fd64e915a17160732b29d343f95f> /usr/lib/libSystem.B.dylib
Thanks for any advice!
Ben Gottlieb pointed out yesterday that if you use blocks anywhere in your application, you'll see a crash similar to this on a pre-4.0 OS while building with the LLVM compiler. To work around this, you can specify the linker flag -weak-lSystem in your Xcode build settings.
Since most of these answers are specific to Xcode 3.x, just wanted to share what I did to fix this with Xcode 4.2.
Under your target in the "Build Phases" tab in the "Link Binary With Libraries" section I added "libSystem.dylib" and made it optional. This fixed the issue iOS 3.x devices while maintaining support for iOS 4.x and 5.0 devices.
If you happen to be using the cocos2d libraries, there is a cleaner way to do this, you should configure the cocos2d target's Deployment target to 3.0