I have been building an app for a client and everything was going smoothly until I started getting this error. This is a unique situation, I've learned how to use instruments and NSZombie however I can't run instruments with NSZombieEnabled on the iPhone only on the simulator. I have to debug this problem in the iPhone because I'm using UIImagePicker to take a picture and the error happens shortly after I take the picture. I'm also using ARC so I can't set release or retain info at all, ARC forbids it, so I doubt its a double release or anything like that. There are 2 possible answers to this question.
1: Does anyone know if I can pass an image into UIImagePicker using photo booth? I could use instruments and NSZombie if I could get passes the camera screen.
2: Is there a way to detect what line would be causing the error without refactoring or commenting out code using the iPhone? Does anybody know an efficient way to track down bad_acces on the iPhone?
Keep in mind I am using ARC and cannot debug this on the simulator. If I take out the UIImagePicker control script the bug does not happen so I've narrowed it down to something in my CameraViewController class. I'm afraid I can't post any code due to a preexisting contract, you would have to be an employee to view source code.
Sorry about the limited information but really I'm looking for an answer about debugging not a direct solution to my exact code problem.
Going to post the backtrace(i think)
(gdb) bt
#0 0x339737e4 in objc_msgSend ()
#1 0x31b30140 in -[UIApplication sendAction:to:from:forEvent:] ()
#2 0x31b300e0 in -[UIApplication sendAction:toTarget:fromSender:forEvent:] ()
#3 0x31b300b2 in -[UIControl sendAction:to:forEvent:] ()
#4 0x31b2fe04 in -[UIControl(Internal) _sendActionsForEvents:withEvent:] ()
#5 0x31b30452 in -[UIControl touchesEnded:withEvent:] ()
#6 0x31b2eddc in -[UIWindow _sendTouchesForEvent:] ()
#7 0x31b2e756 in -[UIWindow sendEvent:] ()
#8 0x31b299fe in -[UIApplication sendEvent:] ()
#9 0x31b29336 in _UIApplicationHandleEvent ()
#10 0x3026c04a in PurpleEventCallback ()
#11 0x3443fce2 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#12 0x3443fca6 in __CFRunLoopDoSource1 ()
#13 0x3443256c in __CFRunLoopRun ()
#14 0x34432276 in CFRunLoopRunSpecific ()
#15 0x3443217e in CFRunLoopRunInMode ()
#16 0x3026b5f2 in GSEventRunModal ()
#17 0x3026b69e in GSEventRun ()
#18 0x31ad0122 in -[UIApplication _run] ()
#19 0x31ace12e in UIApplicationMain ()
#20 0x000034ce in main (argc=1, argv=0x2ffff75c) at /Users/Andrew/Documents/Developing/Xcode Projects/ProjectSVN/Project/trunk/ProjectInterface/ProjectInterface/main.m:16
EXC_BAD_ACCESS doesn't necessarily mean a memory management problem. It could just as easily be caused by memory corruption or other kinds of errors.
Post the backtrace of the crash.
Without code samples it is hard to say, however ARC doesn't totally cover all of your bases. For example, it is possible to get these EXC_BAD_ACCESS errors when objects (classes with delegates) do not exist, yet try to execute callback delegate methods.
To be more specific, let's say I have created a class in viewDidLoad: - let's call it ClassA. In my hypothetical situation, I set my view controller to ClassA's delegate. However, I have not declared a property for ClassA, so there is no reference to it beyond the scope of viewDidLoad:.
Now let's assume ClassA declare a delegate method that is implemented by my view controller. This delegate passes a reference of itself back to the view controller in this delegate method. Because it may or may not be out of scope by this point, BOOM, bad access error. Check for things such as this, where objects do not exist anymore and are being passed to other methods - it is one such way ARC can fail you ;)
Related
Getting this weird crash after updating to Mojave.
Not doing anything special, just creating an NSWindow and calling orderFrontRegardless
Always worked fine before.
1 libsystem_platform.dylib 0x00007fff6610ab5d _sigtramp + 29
2 ??? 0x0000000000000000 0x0 + 0
3 CoreFoundation 0x00007fff39b00bb6 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
4 CoreFoundation 0x00007fff39b00b30 ___CFXRegistrationPost_block_invoke + 63
5 CoreFoundation 0x00007fff39b00a9a _CFXRegistrationPost + 404
6 CoreFoundation 0x00007fff39b08f48 ___CFXNotificationPost_block_invoke + 87
7 CoreFoundation 0x00007fff39a71994 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1642
8 CoreFoundation 0x00007fff39a70d47 _CFXNotificationPost + 732
9 Foundation 0x00007fff3bdab217 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
10 AppKit 0x00007fff3720538b -[NSWindow _setFrameCommon:display:stashSize:] + 3090
11 AppKit 0x00007fff37204766 -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 192
12 AppKit 0x00007fff3720469f -[NSWindow setFrame:display:] + 51
13 AppKit 0x00007fff3727aca9 -[NSWindow _reallyDoOrderWindowAboveOrBelow:relativeTo:findKey:forCounter:force:isModal:] + 1336
14 AppKit 0x00007fff372792a0 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 283
15 AppKit 0x00007fff37a0dce9 -[NSWindow orderFrontRegardless] + 40
Code (it's a console app):
NSWindow *window = [[NSWindow alloc] initWithContentRect:windowRect
styleMask:windowStyle
backing:NSBackingStoreBuffered
defer:NO];
// Since Snow Leopard, programs without application bundles and Info.plist
// files don't get a menubar and can't be brought to the front unless the
// presentation option is changed
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];
[NSApp activateIgnoringOtherApps:YES];
[window makeKeyAndOrderFront:nil];
How do you initialize the app? Do you have NSApplication initialized before using AppKit?
Something like these steps should be necessary in main.m:
#autoreleasepool {
NSApplication* application = NSApplication.sharedApplication;
AppDelegate* delegate = [[AppDelegate alloc] init];
application.delegate = delegate;
[application run];
}
Also your delegate might be getting deallocated, since NSApp holds a weak reference to it.
You indicated that you were dereferencing an uninitialized pointer. But, I don't have enough information from the report you posted to know if this was (perhaps by luck) null, or just garbage memory. I'll assume that at some point you crashed with an EXC_BAD_ACCESS (signal equivalent is SIGBUS or SIGSEGV, depending).
The critical bit of information here was that you had a signal handler installed.
Signal handlers generally (but not always) run on the crashing thread using the same stack. The kernel injects the handler using that _sigtramp function. Upon signal delivery, current stack state contained the information you needed to track down the bad memory access. But, your signal handler was invoked instead. So it ran, mutating the stack as it did.
Then, your signal handler completed somehow. It is possible to configure a signal handler using sigaction such that the process state is restored to the moment just before the crashing event. I'm not sure how your signal handler was configured. But, ultimately, I'm going to assume that the process was allowed to exit.
At this point, Apple's ReportCrash would have been triggered, and would capture backtraces for all threads in whatever state your signal handler left them. This is critical, because that's not necessarily the crashing state.
Adding complexity, backtrace_symbols_fd is not at all safe to use from a signal handler. Async safety is challenging, and running code from a signal handler is highly difficult to get right. There are very few things you can do safely. I'm pretty sure, additionally, that backtrace_symbols_fd allocates memory. So, if your crash was in the memory allocator somewhere, and it sounds like it was, you were definitely at risk for a deadlock. Judging by the backtrace, it seems like that's exactly what might have happened. Check out man sigaction for some details.
Worse, unwinding the stack over a signal handler frame is particularly challenging because of the magic the kernel does to run your handler. That's why that ??? frame is in there.
A summary:
Without a signal handler installed, Apple's ReportCrash would have produced a correct (and likely helpful) backtrace for the crashing thread.
The stack trace you've included isn't great, but it's hard to know exactly why.
It appears that backtrace_symbols_fd didn't do a good job of unwinding, possibly due to it being inappropriate to use from a signal handler, possibly because it isn't backed by a good-enough stack unwinding mechanism for this situation. But, without more information, it's difficult for me to know. I am surprised the the top frame was _sigtramp, though. That doesn't make a lot of sense. It makes me think something might have been going wrong in the signal handler itself. It is possible to crash a second time in your handler.
Apple's backtraces (generated by ReportCrash, backtrace_symbols_fd, or NSThread's callStackReturnAddresses, for example) can definitely be trusted, provided you're careful to use them in safe contexts.
Turns out I had a serious memory bug in a completely different place not even mentioned in the backtrace.
I was dereferencing an uninitialised pointer.
This is the second time it happens.
Do no trust Apple's backtraces when debugging memory errors.
Even with libgmalloc.
I get invariably this error when I close the last window of my app:
Application Specific Information: objc_msgSend() selector name:
respondsToSelector: objc[42729]: garbage collection is OFF
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0
libobjc.A.dylib 0x00007fff8cc9a150 objc_msgSend_vtable5
+ 16 1 com.apple.AppKit 0x00007fff8fbca814 -[NSApplication supplementalTargetForAction:sender:] + 63 2 com.apple.AppKit 0x00007fff8fab91e4
_objectFromResponderChainWhichRespondsToAction + 155 3 com.apple.AppKit 0x00007fff8fab8feb
_NSTargetForSendAction + 3255 4 com.apple.AppKit 0x00007fff8fab832f -[NSApplication targetForAction:to:from:] + 682 5
com.apple.AppKit 0x00007fff8fab7e00 -[NSMenu
_enableItem:] + 403
I confess that the document nib has two windows. I want the "auxiliary window" to be closed and deallocated when the main window is closed. How should I do? Maybe these errors com from here… I'm using Core Data and ARC.
Regards
I found something which seems to solve the problem. But I don't understand what's happening and I really dislike this.
In IB, the file's owner has a "window" outlet who points to the document window; but there is no #property NSWindow window; in the default code of the NS(Persistent)Document.
I had to make a panel a "child window" of the doc's main window, so I add a #property NSWindow mainWindow. The new "mainWindow" outlet points to the same window as the "window" outlet.
And suddenly no more crash, no more zombie. What happened? I'm baffled.
After reflexion: I have added a pointer to the document window, so the ARC counter never reaches zero. I suppose I had a missing reference somewhere to the _window of the NSDocument, which is now balanced by my outlet.
I recently received a crash report from itunes connect. Actually it's the only crash report I got from thousands of users, yet. It's an iPod4,1 device. Interesting parts are:
Date/Time: 2012-02-27 22:53:27.596 +0800
OS Version: iPhone OS 5.0.1 (9A405)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x338958bf __exceptionPreprocess + 163
1 libobjc.A.dylib 0x303891e5 objc_exception_throw + 33
2 UIKit 0x31259749 -[UIViewController mutableChildViewControllers] + 1
3 UIKit 0x31259349 -[UINavigationController pushViewController:animated:] + 37
4 MyApp 0x000081e5 -[MyListController tableView:didSelectRowAtIndexPath:] (MyListController.m:207)
5 UIKit 0x312d3565 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 945
6 UIKit 0x3134bce7 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 159
It seems that the crash occurs when a row from a table view is selected, and a new view controller is pushed into navigation. According to my code, the new view controller is created already, so the crash occurred in UINavigationController.
It doesn't look like the fault of the code I wrote. And I wonder if I'm correct on this? How do I debug this problem?
It sounds like the user got a low-memory warning. UINavigationControllers will retain their views, whereas tabbed ones will pop off the invisible ones. However, the low memory code is still getting called. Check your warning handlers prior to reaching that spot. Also, test by hitting "Simulate Memory Warning" under the hardware menu at all entry and exit points.
http://forums.macrumors.com/showthread.php?t=876419 shows a mess of what happens when you don't.
iphonedevsdk.com/forum/iphone-sdk-development/14225-uinavigationcontrollers-and-didreceivememorywarning.html has a nice comment or so on how to handle this.
I'm betting your view controller loads something and caused the memory warning. Ensure the user can't just stack tons of items on top of each other, and make sure your app is profiled to remove as many leaks as necessary to keep the app up.
The above may not be on the mark, but should be related.
Final note, don't use ARC. Something that disallows calling superclass functions is bound to screw up. If you understand bridging Core Foundation, then perhaps ARC is fine. I personally avoid it at all costs b/c memory becomes randomly handled by Apple's under-the-hood. I've seen their stuff fail way too much
I got it! I had the same problem too and in your code it looks like that a button is pressed, which causes the crash!
Last Exception Backtrace:
0 CoreFoundation 0x338958bf __exceptionPreprocess + 163
1 libobjc.A.dylib 0x303891e5 objc_exception_throw + 33
2 UIKit 0x31259749 -[UIViewController mutableChildViewControllers] + 1
3 UIKit 0x31259349 -[UINavigationController pushViewController:animated:] + 37
4 MyApp 0x000081e5 -[MyListController tableView:didSelectRowAtIndexPath:] (MyListController.m:207)
5 UIKit 0x312d3565 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 945
6 UIKit 0x3134bce7 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 159
Here is my suggestion:
Two things to solve a SIGABRT:
1) SIGABRT happens due to a runtime exception that isn't caught. When this happens there is some info written to the debugger console or the device console that explains the exact reason for the exception. You haven't shown us this text. It starts "Terminating application due to ..."
Show us that text.
2) If you run your app in the debugger and set a breakpoint on the exception throw function the app will stop when the exception is thrown and this will usually be enough to figure it out. Go to the debugger breakpoint pane and at the bottom left is a control that when clicked allows you to set an exception breakpoint.
I've got a program, randomly when a device disconnects or connects I get a crash. when I run a bt command in gdb I get the following:
#0 0x00007fff881cf150 in objc_msgSend_vtable5 ()
#1 0x00007fff8cceabf3 in -[IOBluetoothRFCOMMChannel(IOBluetoothRFCOMMChannelPrivate) processIncomingData:] ()
#2 0x00007fff8cce8ee1 in -[IOBluetoothRFCOMMChannel(IOBluetoothRFCOMMChannelPrivate) handleMachMessage:] ()
#3 0x00007fff8d142ba5 in __NSFireMachPort ()
#4 0x00007fff8ad41e42 in __CFMachPortPerform ()
#5 0x00007fff8ad41cac in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ ()
#6 0x00007fff8ad419db in __CFRunLoopDoSource1 ()
#7 0x00007fff8ad78117 in __CFRunLoopRun ()
#8 0x00007fff8ad77676 in CFRunLoopRunSpecific ()
#9 0x00007fff8c88731f in RunCurrentEventLoopInMode ()
#10 0x00007fff8c88e5c9 in ReceiveNextEventCommon ()
#11 0x00007fff8c88e456 in BlockUntilNextEventMatchingListInMode ()
#12 0x00007fff92404f5d in _DPSNextEvent ()
#13 0x00007fff92404861 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#14 0x00007fff9240119d in -[NSApplication run] ()
#15 0x00007fff9267fb88 in NSApplicationMain ()
#16 0x00000001000020d2 in main (argc=3, argv=0x7fff5fbff8e0) at main.m:13
XCode breaks on NSApplicationMain, not anywhere in my code and I've told it to break on all exceptions. This is leading me to think this is happening insite the bluetooth stack itself. Is this right? Is there any way I can prevent this, or at least try/catch this to clean things up and prevent the crash?
Difficult to say as is, but let's speculate and assume the framework has no bug: you likely setup a delegate on the IOBluetoothRFCOMMChannel and this delegate has been deallocated while the channel still wants to talk to it.
You should make sure your delegate remains alive until the channel is totally shut down or set the channel's delegate to nil.
More generally, this kind of crash indicates access to a deallocated object. The best thing to track this kind of problems is to use Zombie Instruments. It will point you to where the object is accessed, what object it was and also helps you track the object's lifetime.
A bluetooth event is received and dispatched. The dispatch code fails while trying to access the target object. This suggests that an object was destroyed or torn down while it was still the target of pending events.
Take a look at whatever object or structure your code uses to process bluetooth messages. Perhaps it was torn down or corrupted.
A user has sent in a crash report with the stack trace listed below (I have not been able to reproduce the crash myself, but every other crash this user has reported has been a valid bug, even when I couldn't reproduce the effect). The application is a reference-counted Objective-C/Cocoa app.
If I am interpreting it correctly, the crash is caused by attempting to send a drawerDidOpen: message to a deallocated object. The only object that should be receiving drawerDidOpen: is the drawer's delegate object (nowhere does any object register to receive drawer notifications), and the drawer's delegate object is instantiated via the XIB/NIB file, wired to the delegate outlet of the drawer, and not referenced anywhere else.
Given that, how can I protect against the delegate getting dealloc'd before the drawer notification? Or, alternately, what have I misinterpreted that might be causing the crash?
Crash log/stack trace:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
objc_msgSend() selector name: drawerDidOpen:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff8272011c objc_msgSend + 40
1 com.apple.Foundation 0x00007fff87d0786e _nsnote_callback + 167
2 com.apple.CoreFoundation 0x00007fff831bcaea __CFXNotificationPost + 954
3 com.apple.CoreFoundation 0x00007fff831a9098 _CFXNotificationPostNotification + 200
4 com.apple.Foundation 0x00007fff87cfe7d8 -[NSNotificationCenter postNotificationName:object:userInfo:] + 101
5 com.apple.AppKit 0x00007fff8512e944 _NSDrawerObserverCallBack + 840
6 com.apple.CoreFoundation 0x00007fff831d40d7 __CFRunLoopDoObservers + 519
7 com.apple.CoreFoundation 0x00007fff831af8c4 CFRunLoopRunSpecific + 548
8 com.apple.HIToolbox 0x00007fff839b8ada RunCurrentEventLoopInMode + 333
9 com.apple.HIToolbox 0x00007fff839b883d ReceiveNextEventCommon + 148
10 com.apple.HIToolbox 0x00007fff839b8798 BlockUntilNextEventMatchingListInMode + 59
11 com.apple.AppKit 0x00007fff84de8a2a _DPSNextEvent + 708
12 com.apple.AppKit 0x00007fff84de8379 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
13 com.apple.AppKit 0x00007fff84dae05b -[NSApplication run] + 395
14 com.apple.AppKit 0x00007fff84da6d7c NSApplicationMain + 364
15 (my app's identifier) 0x0000000100001188 start + 52
edit: To clarify: This crash happened once in thousands or maybe tens of thousands of virtually-identical usage scenarios. I don't retain/release/alloc/dealloc/anything-memory-management the delegate object anywhere in my code; I don't register any object for any drawer notifications of any kind in my code; my code has no variables (nor ivars) pointing to the delegate object.
What it looks like to me is that when the NIB was unloaded (as in whatever the Cocoa system does when the document window gets closed), somehow the drawer's delegate object was dealloc'd before the drawer object itself, but the Cocoa system is supposed to prevent that from happening (and seems to handle it correctly in the vast majority of cases).
The delegate has been released to the point of deallocation without first being unregistered from the notification center (in this case, the delegation is through the notification center, not directly).
An easy fix is to call NSNotificationCenter's -removeObserver: method from your delegate's -dealloc method.
Check the backtrace -- it is through the notification center that the crash happens. Most likely, when the class is connected via setDelegate: (via the NIB file), it is done so as a notification observer.
Regardless, the relationship between notification center and your object is the same as between the object in IB and your object; weak. That is, there is no retain and, thus, your delegate is being freed too early (or, alternatively, you are over-releasing the object somewhere).
In any case, you need to make sure your delegate is retained by something somewhere for the duration of its usefulness.