I'm developing a SDK for iOS and i put some assert() in the code to help me catching the bugs. It's working great when using the simulator but if I build my App (Debug-iphoneos) on a device, unplug it from my mac and leave it for testing, the crash log I get from an assertion failure is impossible to understand.
real sample from a basic nil assertion failure:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Triggered by Thread: 0
Filtered syslog:
None found
Global Trace Buffer (reverse chronological seconds):
10.153264 CFNetwork 0x0000000021bb897d TCP Conn 0x14dbd8c0 complete. fd: 9, err: 0
10.154690 CFNetwork 0x0000000021bb9a7f TCP Conn 0x14dbd8c0 event 1. err: 0
10.288093 CFNetwork 0x0000000021bb9afd TCP Conn 0x14dbd8c0 started
10.293561 CFNetwork 0x0000000021bff26f Creating default cookie storage with default identifier
10.293562 CFNetwork 0x0000000021bff24b Faulting in CFHTTPCookieStorage singleton
10.293562 CFNetwork 0x0000000021c418f7 Faulting in NSHTTPCookieStorage singleton
10.514965 CFNetwork 0x0000000021bb897d TCP Conn 0x14d88140 complete. fd: 4, err: 0
10.514965 CFNetwork 0x0000000021bb9a7f TCP Conn 0x14d88140 event 1. err: 0
10.789507 CFNetwork 0x0000000021bb9afd TCP Conn 0x14d88140 started
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libswiftCore.dylib 0x00509e10 0x3af000 + 1420816
1 MyFramework 0x002ddfec 0x24f000 + 585708
Any chance I can get more information from the crash log ? I tried atos -arch armv7 -o MyApp.app/MyApp 0x24f000 without any success (returning 0x24f000)
Solved with this post Atos does not symbolicate system frameworks/libraries properly
here I had to extract my framework from the .app and do
xcrun atos -arch armv7 -o MyFramework.framework/MyFramework -l 0x24f000 0x002ddfec
(notice the reverse order of memory adresses)
Related
The app is approved by Apple but it keep on crashing when downloaded from the App Store, The app works fine in Simulator.
Here's the crashlog.
From my searches it was indicated that it's due to Parse and but even after updating Parse and re submitting to Apple Review the app still crashes
Incident Identifier: 1EA2D752-986F-45F0-B00D-258BBDAFFDBE
CrashReporter Key: 16f85ba0a0b881573e6146c9e7ff8890a75db660
Hardware Model: iPhone7,2
Process: Roadster [429]
Path: /private/var/containers/Bundle/Application/5BF8E8BA-B069-40C7-9345-5FB298584CFF/Roadster.app/Roadster
Identifier: App.Roadster
Version: 4 (4.5)
Code Type: ARM-64 (Native)
Parent Process: launchd [1]
Date/Time: 2016-06-24 02:16:02.02 +0530
Launch Time: 2016-06-24 02:15:47.47 +0530
OS Version: iOS 9.3.2 (13F69)
Report Version: 105
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
Filtered syslog:
None found
Global Trace Buffer (reverse chronological seconds):
0.224703 CFNetwork 0x0000000184525990 TCP Conn 0x154f8b920 starting SSL negotiation
0.225145 CFNetwork 0x00000001845c7f18 TCP Conn 0x154f8b920 complete. fd: 19, err: 0
0.226301 CFNetwork 0x00000001845c9444 TCP Conn 0x154f8b920 event 1. err: 0
0.849718 CFNetwork 0x00000001845c951c TCP Conn 0x154f8b920 started
11.240709 CFNetwork 0x0000000184525a80 TCP Conn 0x154db8b00 SSL Handshake DONE
12.478336 CFNetwork 0x0000000184525990 TCP Conn 0x154db8b00 starting SSL negotiation
12.479360 CFNetwork 0x00000001845c7f18 TCP Conn 0x154db8b00 complete. fd: 15, err: 0
12.479584 CFNetwork 0x00000001845c9444 TCP Conn 0x154db8b00 event 1. err: 0
12.865094 CFNetwork 0x00000001845c951c TCP Conn 0x154db8b00 started
12.889732 CFNetwork 0x0000000184525a80 TCP Conn 0x154d799c0 SSL Handshake DONE
13.189451 CFNetwork 0x0000000184525a80 TCP Conn 0x154e87ad0 SSL Handshake DONE
13.377730 CFNetwork 0x0000000184525a80 TCP Conn 0x154d5cae0 SSL Handshake DONE
13.667209 CFNetwork 0x0000000184525a80 TCP Conn 0x154d3a890 SSL Handshake DONE
13.726884 CFNetwork 0x0000000184525990 TCP Conn 0x154d799c0 starting SSL negotiation
13.731394 CFNetwork 0x00000001845c7f18 TCP Conn 0x154d799c0 complete. fd: 13, err: 0
13.735323 CFNetwork 0x00000001845c9444 TCP Conn 0x154d799c0 event 1. err: 0
13.895899 CFNetwork 0x0000000184525990 TCP Conn 0x154e87ad0 starting SSL negotiation
13.896511 CFNetwork 0x00000001845c7f18 TCP Conn 0x154e87ad0 complete. fd: 7, err: 0
13.898156 CFNetwork 0x00000001845c9444 TCP Conn 0x154e87ad0 event 1. err: 0
13.991708 CFNetwork 0x0000000184525990 TCP Conn 0x154d3a890 starting SSL negotiation
13.992223 CFNetwork 0x00000001845c7f18 TCP Conn 0x154d3a890 complete. fd: 12, err: 0
13.993698 CFNetwork 0x00000001845c9444 TCP Conn 0x154d3a890 event 1. err: 0
14.076219 CFNetwork 0x0000000184525990 TCP Conn 0x154d5cae0 starting SSL negotiation
14.076820 CFNetwork 0x00000001845c7f18 TCP Conn 0x154d5cae0 complete. fd: 6, err: 0
14.078054 CFNetwork 0x00000001845c9444 TCP Conn 0x154d5cae0 event 1. err: 0
14.227695 CFNetwork 0x00000001845c951c TCP Conn 0x154d799c0 started
14.229171 CFNetwork 0x00000001845c951c TCP Conn 0x154d3a890 started
14.518114 CFNetwork 0x00000001845c951c TCP Conn 0x154e87ad0 started
14.519612 CFNetwork 0x0000000184623e5c Creating default cookie storage with default identifier
14.519612 CFNetwork 0x0000000184623e28 Faulting in CFHTTPCookieStorage singleton
14.519612 CFNetwork 0x0000000184675e50 Faulting in NSHTTPCookieStorage singleton
14.529775 CFNetwork 0x00000001845c951c TCP Conn 0x154d5cae0 started
Answering myself :
Problem was due to Parse, Update Parse framework and it should solve the problem
I recently upgraded my MBP to El Capitan and XCode 7.3.1 but when I try to run my project in Simulator I get "DTAssetProviderService could not start" error. I've tried clean, restart both tools, and restart my machine, but the issue persists. In /var/log/system.log here is the pertinent logs around that time:
May 18 10:00:38 lsacco-mac kernel[0]: com.apple.dt.Xco[6277] triggered unnest of range 0x7fff92800000->0x7fff92a00000 of DYLD shared region in VM map 0x3ab4b61dbef
May 18 10:00:44 lsacco-mac kernel[0]: xpcproxy[6300] triggered unnest of range 0x7fff8f200000->0x7fff8f400000 of DYLD shared region in VM map 0x3ab4b61dbe725e15. While not abnormal for debuggers, this increases system memory footprint until the target exits.
May 18 10:00:44 lsacco-mac kernel[0]: AMFI: com.apple.dt.ins(pid 6300) - [deny-mmap] mapped executable file has no team identifier in its signature: /usr/local/lib/libwep
May 18 10:00:44 lsacco-mac com.apple.xpc.launchd[1] (com.apple.dt.instruments.dtarbiter.xpc[6300]): Service exited due to signal: Trace/BPT trap: 5
May 18 10:00:44 lsacco-mac DTServiceHub[6299]: dtarbiter XPC call failure (register_client_with_singleton): (os/kern) failure
May 18 10:00:44 lsacco-mac Xcode[6059]: +[DTServiceHubClient localConnectionWithAuthorization:returningServerPid:]: failed to establish connection with DTServiceHub service '/Applications/Xcode.app/Contents/SharedFrameworks/DVTInstrumentsFoundation.framework/Resources/DTServiceHub'
May 18 10:00:44 lsacco-mac Xcode[6059]: iPhoneSimulator: Unable to connect to "com.apple.instruments.deviceservice.lockdown" (Error Domain=DTServiceHubClient Code=-11 "unable to contact local DTServiceHub to bless simulator connection" UserInfo={NSLocalizedDescription=unable to contact local DTServiceHub to bless simulator connection})
May 18 10:00:44 lsacco-mac kernel[0]: xpcproxy[6301] triggered unnest of range 0x7fff8f200000->0x7fff8f400000 of DYLD shared region in VM map 0x3ab4b61dd3a83ab5. While not abnormal for debuggers, this increases system memory footprint until the target exits.
May 18 10:00:44 lsacco-mac com.apple.xpc.launchd[1] (com.apple.ReportCrash[6301]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash
May 18 10:00:44 lsacco-mac ReportCrash[6301]: Saved crash report for com.apple.dt.instruments.dtarbiter[6300] version ??? to /Users/lsacco/Library/Logs/DiagnosticReports/com.apple.dt.instruments.dtarbiter_2016-05-18-100044_lsacco-mac.crash
The crash file simply had this:
Process: com.apple.dt.instruments.dtarbiter [6300]
Path: /private/var/run/*/com.apple.dt.instruments.dtarbiter
Identifier: com.apple.dt.instruments.dtarbiter
Version: ???
Code Type: X86-64 (Native)
Parent Process: ??? [1]
User ID: 0
Date/Time: 2016-05-18 10:00:44.332 -0700
OS Version: Mac OS X 10.11.5 (15F34)
Report Version: 11
Anonymous UUID: D0D71B50-8DA8-77BD-34D9-F97A39EE7F20
Sleep/Wake UUID: 1F71874E-C351-4020-AAF2-D5B9BE9992B9
Time Awake Since Boot: 5400 seconds
Time Since Wake: 2000 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
dyld: launch, loading dependent libraries
Dyld Error Message:
Library not loaded: /usr/local/lib/libwep
Referenced from: /private/var/run/*/com.apple.dt.instruments.dtarbiter
Reason: no suitable image found. Did find:
/usr/local/lib/libwep: mmap() error 1 at address=0x10E599000, size=0x00008000 segment=__TEXT in Segment::map() mapping /usr/local/lib/libwep
Binary Images:
0x7fff6ccff000 - 0x7fff6cd3625f dyld (360.22) <A468D85E-D8D6-3461-8C99-49D3B9ACFC63> /usr/lib/dyld
0x7fff8721b000 - 0x7fff87586657 libobjc.A.dylib (680) <D55D5807-1FBE-32A5-9105-44D7AFE68C27> /usr/lib/libobjc.A.dylib
0x7fff92f8c000 - 0x7fff93402fff com.apple.CoreFoundation (6.9 - 1258.1) <943A1383-DA6A-3DC0-ABCD-D9AEB3D0D34D> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x7fff93c2e000 - 0x7fff93f82fff com.apple.Foundation (6.9 - 1259) <71A9D3A0-0B1F-3E3A-86F3-1486365A6EF2> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x7fff9cb24000 - 0x7fff9cb25ffb libSystem.B.dylib (1226.10.1) <C5D09FE1-CC70-383E-AC27-18602F2EDEC4> /usr/lib/libSystem.B.dylib
This post references several fixes relating to restarting and cleaning different things but none worked for me. Any other ideas?
This turns out to be an issue with having WebSense installed by my IT department. It is known to inject libraries into other processes such as Simulator. Once removed, it was working again.
i have a crash on iOS from the wild which looks something like the following
Exception Type: SIGTRAP
Exception Codes: TRAP_BRKPT at 0xe7ffdefe
Crashed Thread: 0
Application Specific Information:
*** Terminating app due to uncaught exception '', reason: ''
Thread 0 Crashed:
0 MyApp 0x002bf4d8 0xdb000 + 1983704
1 MyApp 0x002bf4f4 0xdb000 + 1983732
2 MyApp 0x004e17ef 0xdb000 + 4220911
first question: I'm under the impression SIGTRAP is related to the debugger. how does this happen in production?
I am able to sylbolicate correctly, but not this TRAP_BRKPT at 0xe7ffdefe
I think knowing what lives at 0xe7ffdefe will help me figure out what's going on. so the the second question is how do i find out what is living at 0xe7ffdefe?
I've tried running
atos -l -arch armv7 -o ./MyApp 0xe7ffdefe
and got the output
0x00004014 (in MyApp)
0x0000400a (in MyApp)
Edit:
figured i might as well provide the symbolicated results
0 MyApp 0x000000010027c5d8 MyController.viewDidLoad() -> () (MyViewController.swift:26)
1 MyApp 0x000000010027c5f8 #objc MyViewController.viewDidLoad() -> () (MyViewController.swift:0)
where line 26 is self.webView.loadHTMLString(self.staticScreen.body, baseURL: nil)
When i try to Analyze my code (Product -> Analyze), the xcode crash with this title "clang quit unexpectedly"
Process: clang [10074]
Path: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
Identifier: clang
Version: 3.1 (318.0.61)
Code Type: X86-64 (Native)
Parent Process: clang [10073]
Date/Time: 2012-07-13 18:46:29.862 +0100
OS Version: Mac OS X 10.7.4 (11E53)
Report Version: 9
Interval Since Last Report: 140604 sec
Crashes Since Last Report: 50
Per-App Crashes Since Last Report: 39
Anonymous UUID: E974A614-4831-478E-8B68-8FE005A98F19
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 000000010180f000-00000001029c8000 [ 17.7M] r-x/rwx SM=COW /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 clang 0x00000001018dc780 clang::Stmt::getSourceRange() const + 16
1 clang 0x00000001021ce0c6 _ZL22getValidSourceLocationPKN5clang4StmtEN4llvm12PointerUnionIPKNS_15LocationContextEPNS_19AnalysisDeclContextEEE + 86
2 clang 0x00000001021ce5d3 clang::ento::PathDiagnosticLocation::genLocation(clang::SourceLocation, llvm::PointerUnion) const + 35
my guest is because LLVM ? i have Apple LLVM compiler 3.1
Thanks!
Edit:
Xcode Version 4.3.3 (4E3002)
I have a file that always crashes clang when analyzed. I submitted abut report on it and Apple dupped the bug - so obviously they know of some bugs already. Note that Xcode 4.4 will be released in a week or two with llvm 4.0 so just wait for it, and if you still get crashes please enter a bug report at bug reporter.apple.com
Edit: my bug report was against 4.3.3
I have an iOS app with the following (selected) build settings in XCode 4.0.1:
Architecture = Standard (armv6 armv7)
Base SDK = Latest iOS (iOS 4.3)
iOS Deployment Target = iOS3.1
Other linker flags = -lxml2 -weak-library /usr/lib/libSystem.B.dylib
Under Targets/Build Phases, I have libSystem.B.dylib as Optional (Link Binary With Libraries).
On a 1st gen iPod Touch, I'm getting the following results:
Debug Build, C/C++ Compiler Version = LLVM Compiler 2.0, all OK
Ad Hoc Release Build, C/C++ Compiler Version = GCC 4.2, all OK
Ad Hoc Release Build, C/C++ Compiler Version = LLVM GCC 4.2, all OK
Ad Hoc Release Build, C/C++ Compiler Version = LLVM Compiler 2.0, crash a few seconds after starting.
In case 4., the crash report looks like this:
Incident Identifier: 10B8B9C5-0FA5-4C83-AB13-4C3F59D5962D
CrashReporter Key: 29f7901a33e9b055c9034cd051902ea0c87e61f6
Process: TPE [1484]
Path: /var/mobile/Applications/4FA4C8CA-DB5D-4096-8458-C76382E68D02/TPE.app/TPE
Identifier: TPE
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2011-04-09 17:56:58.188 +1000
OS Version: iPhone OS 3.1.3 (7E18)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0000000000 0 + 0
Thread 1:
0 libSystem.B.dylib 0x00001488 mach_msg_trap + 20
1 libSystem.B.dylib 0x00004064 mach_msg + 60
etc.
The crash happens after a number of routines in my code have executed (I can see console output confirming it).
Does anyone have any ideas what would cause this to work under GCC4.2, but crash under LLVM2?
It's just a wild guess, but there was a compiler bug recently in llvm2 that made our app crash the same way. It only happened in release mode with full optimization and only on older devices (probably a specific processor). We switched back to gcc and everything was fine again. Apple updated their compiler in mean time which "fixes bugs for iOS", but we didn't test it yet.
The same problem still occurs with XCode 4.2 (4D199) when code is generated with Apple LLVM compiler 3.0.
AdHoc App works fine on iOS5 on simulator, iPad1 and iPhone4.
Same AdHoc code crashes on iPhone 3 and iPod3 on iOS 4.2.1 (8C148).
Debug code works fine on all platforms.
When the problem occurs the console log shows the following:
SpringBoard[25] <Warning>: Received memory warning. Level=1
MobileSafari[283] <Warning>: Received memory warning. Level=1
configd[23] <Notice>: jetsam: kernel memory event (93), free: 241, active: 1109, inactive: 760, purgeable: 0, wired: 7878
configd[23] <Notice>: jetsam: kernel termination snapshot being created
com.apple.launchd[1] <Notice>: (UIKitApplication:com.apple.mobilesafari[0xc614]) Exited: Killed
com.apple.launchd[1] <Notice>: (UIKitApplication:com.myapp.test[0x47db]) Exited: Killed
SpringBoard[25] <Warning>: Application 'MyApp' exited abnormally with signal 9: Killed
Peak memory usage of the App is a couple Mb. The debug code never reaches a critical memory limit.
The problem disappears when either:
Optimization Level for AdHoc is set to None (-O0)
The compiler is changed to LLVM GCC 4.2
So far, extensive analyzes of code and memory management have not provided an indication what might be causing this. It seems like a compiler bug...