I am using Bugsense in my app to get crash reports.
I have a repeating bug with SIGSEGV and no other details about it.
I tried to symbolicate the report but I get this:
0 libobjc.A.dylib 0x33417f78 0x33414000 + 16248
1 CoreFoundation 0x36f651fb 0x36f4d000 + 98811
2 Foundation 0x32c42747 0x32b9e000 + 673607
3 CoreFoundation 0x36fdaad3 0x36f4d000 + 580307
4 CoreFoundation 0x36fda29f 0x36f4d000 + 578207
5 CoreFoundation 0x36fd9045 0x36f4d000 + 573509
6 CoreFoundation 0x36f5c4a5 CFRunLoopRunSpecific + 300
7 CoreFoundation 0x36f5c36d CFRunLoopRunInMode + 104
8 GraphicsServices 0x35123439 GSEventRunModal + 136
9 UIKit 0x35205cd5 UIApplicationMain + 1080
10 English Club 0x00036a2b 0x34000 + 10795
It does not point to any of my classes (In the last line 'English Club' is the name of my app).
Does that mean that this is a bug in apple classes? how can I parse this report to get somthing helpful (like what are the +1234334 numbers in this case etc.
Thank you all
Shani
Does that mean that this is a bug in apple classes?
No.
how can I parse this report to get somthing helpful
Recompile with debug symbols enabled, and run the app in the debugger. Then, if everything was done right, you'll get a symbolicated stack trace.
what are the +1234334 numbers in this case
They're offsets from the beginning of the particular function address - and you're most likely not interested in them.
Your best bet here is to enable zombies and rerun in the debugger and try to reproduce the crash manually. The bug is likely somwhere in your code where you set a delegate that points to one of your objective C objects. For example, see this question which is much like yours: SIGSEGV SEGV_ACCERR Crash Reports - What to do?
Related
I experiencing a crash in my app:
Thread 0 name:
Thread 0 Crashed:
0 LogoQuizAC 0x0000000104705218 __hidden#563_ + 0 (__hidden#957_:0)
1 LogoQuizAC 0x0000000104705218 _hidden#18_ + 592 (__hidden#957_:135)
2 LogoQuizAC 0x000000010470503c __hidden#564_ + 48 (__hidden#456_:0)
3 LogoQuizAC 0x000000010470503c _hidden#18_ + 116 (__hidden#957_:135)
4 LogoQuizAC 0x00000001046fcd6c _hidden#17_ + 504 (__hidden#454_:96)
5 LogoQuizAC 0x00000001046fcea0 _hidden#20_ + 36 (__hidden#456_:0)
6 Foundation 0x0000000182770b20 __NSFireTimer + 68 (NSTimer.m:270)
7 CoreFoundation 0x0000000181355fa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1807)
8 CoreFoundation 0x0000000181355ba0 __CFRunLoopDoTimer + 1064 (CFRunLoop.c:2415)
9 CoreFoundation 0x0000000181354ffc __CFRunLoopDoTimers + 328 (CFRunLoop.c:2575)
10 CoreFoundation 0x000000018134eee4 __CFRunLoopRun + 1936 (CFRunLoop.c:3090)
11 CoreFoundation 0x000000018134e21c CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
12 GraphicsServices 0x0000000198f18784 GSEventRunModal + 164 (GSEvent.c:2259)
13 UIKitCore 0x0000000183d8eee8 -[UIApplication _run] + 1072 (UIApplication.m:3253)
14 UIKitCore 0x0000000183d9475c UIApplicationMain + 168 (UIApplication.m:4707)
15 LogoQuizAC 0x000000010453a404 main + 68 (RLockedCell.swift:21)
16 libdyld.dylib 0x000000018100e6b0 start + 4
I tried almost everything but can symbolicate the crash.
I tried using symbolicatecrash followed by these posts:
(_hidden#919_:0) inside crash symbolication file
Why aren't the crashlogs from Testflight symbolicating in Xcode?
Xcode Crash Organizer does Not Symbolicate .xccrashpoint Files
How to symbolicate crash log with Xcode 8?
how Symbolicate a crash file using xcarchive
How to symbolicate crash log Xcode?
But without any success.
What am I doing wrong? How can I figure out what causing the crash?
The good news that it is crashing in your code, not in Operating Systems or Library code, so you have a good chance to debug it. Your code that is crashing is running off a timer. Sometimes these bugs are seen because in testing, you are just testing the app. But in the real world, those timers fire when you are not expecting them.
For example, someone ran your app, then put it into the background when using another app, or for example they received a phone call whilst using the app. If you attach the full contents of the .crash file, it will give more information on the cause of the crash.
Another thing you can do is place asserts into your code, such as in your timer callback functions for each object you are relying on being non-null.
You may find that your app is trying to draw onto the screen but is in the background. This is a common reason for a crash seen in the field for games that use timers. That may sound like a generalisation but it is a suggestion to try and make you think differently about the real world environment your customers face which can the reason for the failure.
I have several production iOS apps that all use the Fabric framework for Crashlytics and Twitter integration. For the past few months I've been seeing a low-level crash show up in Crashlytics, but I have been unable to duplicate it.
Here is the stack trace and about all I have to go on:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x0000000194eec174 objc_release + 20
1 libobjc.A.dylib 0x0000000194eed724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
2 CoreFoundation 0x0000000183141074 _CFAutoreleasePoolPop + 28
3 Foundation 0x0000000184072588 -[NSAutoreleasePool release] + 148
4 UIKit 0x0000000187d443f4 -[UIApplication _run] + 588
5 UIKit 0x0000000187d3ef40 UIApplicationMain + 1488
6 GT CFPlus 0x000000010000e7ec main (main.m:16)
7 libdyld.dylib 0x000000019557ea08 start + 4
At that point I get an EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000e005bec8 message.
I've done the standard Googling of the problem and based on posts like this it seems obvious that I'm doing something that ARC doesn't like. I just can't figure out what that might be. I have tried turning on NSZombies and have also run my code against an Objective-C static analysis tool with no luck on either.
My question is: has anyone run into anything similar, especially when using the Fabric framework? If so, is this something that could be buried in the framework, or is it my own doing?
I have a problem with my iOS app crashing. It uses core data (one managed object context) and ARC but also has a separate SQLite database, which can be fairly large. I am getting crash reports for it with the error: EXC_BAD_ACCESS and usually with the code: KERN_INVALID_ADDRESS
The problem is that every single crash happens in a different place (there are over 30) and that usually those places don't usually include any of my code in the call stack. I think, therefore that I am doing something fundamentally wrong which is causing these errors to occur.
I have tried turning on NSZombiesEnabled, but then I find that the errors don't occur. Also, I have tried turning on core data debugging (level 1), but I find the same there too. The errors occur across a range of devices and operating systems. The crash reports show between 3.0 to 148.0 mb or ram remaining. All of the crashes are on the main thread.
So my question comes in two parts:
1) I can't find any reference to there being a problem using a separate SQLLite database in a core data project. Is there any potential pitfalls to doing this and docs on how to avoid those pitfalls?
2) Does this patten of errors suggest anything in particular which I may be doing incorrectly?
I have added a single crash report on the off chance it reveals something which my question does not:
0
com.apple.main-thread Crashed
0 CoreFoundation CFRetain + 19
1 CoreFoundation __CFRunLoopDoTimer + 690
2 CoreFoundation __CFRunLoopDoTimer + 690
3 CoreFoundation __CFRunLoopRun + 1232
4 CoreFoundation CFRunLoopRunSpecific + 356
5 CoreFoundation CFRunLoopRunInMode + 104
6 GraphicsServices GSEventRunModal + 74
7 UIKit UIApplicationMain + 1120
8 cleverme
main.m line 14
main
I'm using BugSense to track crashes from an iOS App. Recently I noticed problems symbolicating stack traces from live usage.
The problem is that Apple introduced address space randomization with iOS 4.3 so that the stack address of interest cannot solely be used to retrieve the correct methods that caused the crash.
Currently I'm trying to get the correct address by calculating
symbol address = slide + stack address - load address
I already have slide and stack address but from my understanding the load address can only be found in the crash report which I cannot get via BugSense.
The stack trace looks like
0 CoreFoundation 0x342723e7 + 162
1 libobjc.A.dylib 0x3bf63963 objc_exception_throw + 30
2 CoreFoundation 0x3427229d + 0
3 Foundation 0x34b48fa3 + 90
4 UIKit 0x360b5bd9 + 7640
5 MyApp 0x000c6e99 0xb3000 + 81561
6 UIKit 0x3623c2ff 0x3607e000 + 1827583
7 UIKit 0x361b8737 0x3607e000 + 1287991
8 UIKit 0x361a9869 0x3607e000 + 1226857
9 UIKit 0x361a97ad 0x3607e000 + 1226669
10 CoreFoundation 0x34247941 0x341b0000 + 620865
11 CoreFoundation 0x34245c39 0x341b0000 + 613433
12 CoreFoundation 0x34245f1d 0x341b0000 + 614173
13 CoreFoundation 0x341b923d CFRunLoopRunSpecific + 356
14 CoreFoundation 0x341b90c9 CFRunLoopRunInMode + 104
15 GraphicsServices 0x37d9733b GSEventRunModal + 74
16 UIKit 0x360d52b9 UIApplicationMain + 1120
17 MyApp 0x000b61bf 0xb3000 + 12735
18 MyApp 0x000b4a08 0xb3000 + 6664
Is there another way to symbolicate this address or to get the respective load address?
The load address is 0xb3000.
Luckily you have the symbols stripped from your app binary, otherwise this wouldn't be visible.
Also this crash happened because of an exception being thrown, so the crash report should give you a Last Exception Backtrace showing where the actual exception happened and the actual exception reason. It is likely that the call in line 5 of the posted stack trace doesn't give you a lot of information on that. The crash information you are getting looks pretty limited :(
I'm using crittercism to get crash report on my app.
It's working pretty well but I got a crash with a stacktrace which is not really helpful.
0 libobjc.A.dylib 0x3b16c5b0 objc_msgSend + 16
1 Foundation 0x33d6b0f5 __NSThreadPerformPerform + 461
2 CoreFoundation 0x33429683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
3 CoreFoundation 0x33428ee9 __CFRunLoopDoSources0 + 213
4 CoreFoundation 0x33427cb7 __CFRunLoopRun + 647
5 CoreFoundation 0x3339aebd CFRunLoopRunSpecific + 357
6 CoreFoundation 0x3339ad49 CFRunLoopRunInMode + 105
7 GraphicsServices 0x36f712eb GSEventRunModal + 75
8 UIKit 0x352b0301 UIApplicationMain + 1121
9 myapp 0x00024c2f main (main.m:14)
The crash is symbolicated but there is no information to point me at the exact place of the crash.
I think it could be an object released too soon, but since it's a random bug and I don't know where it happen its really hard to track it down.
How do I convert this stacktrace or the crash report to a human readable one?
This crash is almost exactly identical with my main headache-causing crash at the moment, and I don't know what to do about it. The only change in my crash log is main (main.m:6) instead of your main (main.m:14).
So far I've found this:
SIGABRT crash on __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
Rejected iPhone app has strange crash logs
The accepted answers suggests that it could be related to misuse of performSelector.
This guy also has the same crash, but with no suggested solution:
http://comments.gmane.org/gmane.comp.handhelds.phonegap/24494
There are other, similar crash logs out there that have a curious addition:
...
CoreFoundation 0xXXXXXXXX -[NSObject performSelector:withObject:] + XX <- additional line
Foundation 0xXXXXXXXX __NSThreadPerformPerform + XXX
CoreFoundation 0xXXXXXXXX __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + XX
...
Which again suggests that it's related to performSelector, but that's still speculation.