Crash report

Question

Just spent some time ... crashing without realizing it. This is a classic:

Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010 

This leads me to a memory issue by accessing the wrong 0x10 address

My concern is that I have a crash report and a stack trace that are different:

---

Failure report sent by user (successfully marked with a symbol):

 Thread 0 Crashed: 0 libobjc.A.dylib 0x000027d8 objc_msgSend + 16 1 UIKit 0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54 2 QuartzCore 0x0002d8c2 run_animation_callbacks(double, void*) + 286 3 QuartzCore 0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116 4 CoreFoundation 0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8 5 CoreFoundation 0x000562a6 __CFRunLoopDoTimer + 854 6 CoreFoundation 0x0002779e __CFRunLoopRun + 1082 7 CoreFoundation 0x00027270 CFRunLoopRunSpecific + 224 8 CoreFoundation 0x00027178 CFRunLoopRunInMode + 52 9 GraphicsServices 0x000045ec GSEventRunModal + 108 10 GraphicsServices 0x00004698 GSEventRun + 56 11 UIKit 0x0000411c -[UIApplication _run] + 396 12 UIKit 0x00002128 UIApplicationMain + 664 13 MyApp 0x00003158 main (main.m:13) 14 MyApp 0x00003120 0x1000 + 8480 

---

Alarm stack trace (bound in real time by an exception handler)

 0 MyApp 0x000d79c3 0x0 + 883139 1 MyApp 0x000d790b 0x0 + 882955 2 libSystem.B.dylib 0x302765d3 _sigtramp + 42 3 UIKit 0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60 4 QuartzCore 0x33a178c9 _ZL23run_animation_callbacksdPv + 292 5 QuartzCore 0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122 6 CoreFoundation 0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14 7 CoreFoundation 0x3084e2ad __CFRunLoopDoTimer + 860 8 CoreFoundation 0x3081f7a5 __CFRunLoopRun + 1088 9 CoreFoundation 0x3081f277 CFRunLoopRunSpecific + 230 10 CoreFoundation 0x3081f17f CFRunLoopRunInMode + 58 11 GraphicsServices 0x31e445f3 GSEventRunModal + 114 12 GraphicsServices 0x31e4469f GSEventRun + 62 13 UIKit 0x31e51123 -[UIApplication _run] + 402 14 UIKit 0x31e4f12f UIApplicationMain + 670 15 MyApp 0x0000315f 0x0 + 12639 16 MyApp 0x00003128 0x0 + 12584 

Both are different, and the stack trace indicates a failure in my code, but at the addresses I can neither symbolize nor identify. I think the crash report indicates that the message was sent to the released instance ... Probably related to using:

 + (void)setAnimationDelegate:(id)delegate + (void)setAnimationDidStopSelector:(SEL)selector 

So, here are (finally!) My questions:

• What explains the differences between magazines? (libobjc.A vs libSystem.B ??)
• Does SIGBUS come from my code or from UIKit?
• How can I decrypt the top stack trace addresses (0x000d79 ??, which atos do not allow)
• Is this what I think is the problem with the animation not ending? similar to this> How to disable a delegate in a UIView setAnimationDelegate: call?
• AFAIK, setAnimationDelegate must be kept by the delegate ... Someone who needs to confirm?

EDIT : I can't use NSZombiesEnabled , this is a NSZombiesEnabled report from a published application, a crash that I could not reproduce in the development environment. I just have these logs for diagnosis.

Answer 1

Answering my question, Latner weeks, since I didn’t have the corresponding answers, most of them guess, I would like to get more accurate answers, but I think my question was unclear:

• The difference comes from the log source, the sighandler and CrashReporter services, which occur at different times, and then the stack traces are slightly different.
• SIGBUS comes from UIKit, but the chances are great that with a callback initiated from my code that ends with the released object. These stack traces are a pain for debugging when you cannot reproduce the problem, because it basically tells you: “I crash somewhere because of the animation ”, which, where ... I still do not understand for sure. It could be anywhere, and it could also be an Apple iOS bug.
• The first addresses on the stack are just a dead end, where any trace of the SIGBUS stack ends when the issued object is called. They vary in compilation (version), but are the same on any device, so they cannot be symbolized. (I'd like a technical explanation for this, rather than guessing)
• & 5. Probably, I solved this error, becoming more "aggressive" when canceling the animation in some cases, for example, when releasing some types ...

Hope this helps someone.

Answer 2

Whenever I see objc_msgSend at the top, my confidence in the remaining stack is small, because the error that gives this tends to do bad things on the stack.

GuardMalloc is good for this because trying to do something with freed up space will crash the application right away in the debugger. The stack will be intact. (This makes the application very slow, but it is a very powerful tool.)

Two stacks are the same as calling the UIViewAnimationState method. The version received from your exception handler shows names with a garbled C ++ name instead of the usual names specified in the crash log.

(As I understand it) _sigtramp is a system method to call your signal handler and is not suitable for Signal Trampoline. Stack entries other than this are probably your signal handler code.

Answer 3

You should try NSZombie to get information about which object you released. This is a very useful tool when you get EXC_BAD_ACCESS.

To activate NSZombie, follow these steps:

• Get information about the artist.
• Go to the options tab.
• In the section "Variables to be set in the environment:" add:

Name: NSZombieEnabled Value: YES

Then run the application as usual, and when it works, it should tell you which freed object received the message.

Answer 4

1. I am not 100% sure, but I think the discrepancy is due to how the application runs. In the second log, it looks like you are running the application through Xcode in debug mode, a sigtramp signal has been sent to indicate an EXC_BAD_ACCESS error.

2. Your code - an error may occur from the UIKit library, but this is the result of a problem with your use.

3. Here NSZombieEnabled will make your life a lot easier! If you run the application with the NSZombieEnabled flag, Xcode will store zombie objects instead of freed objects. When a zombie object is sent a message, the process will mask the error and tell you which object was sent.

If you are using Xcode 4, enable NSZombieEnabled using the following instructions ...

How to configure NSZombieEnabled in Xcode 4?

For older versions, follow these instructions ...

http://www.cocoadev.com/index.pl?NSZombieEnabled

4 .. Indeed, your animation delegate was released before the animation ended.