I have an older app that I converted to use ARC. The original version did not have memory leaks, and I fixed all of the errors after the conversion using the memory diagnostics in the debugger. Occasionally, the app will crash and the stack trace looks like ARC is stuck in either an infinite retain or release cycle, like this:
0 CoreFoundation 0x329046a6 CFRelease + 46
1 CoreFoundation 0x329046da CFRelease + 98
2 CoreFoundation 0x329046da CFRelease + 98
3 CoreFoundation 0x329046da CFRelease + 98
4 CoreFoundation 0x329046da CFRelease + 98
Unfortunately, the stack traces cut off at 512 entries, so I can't see where this chain started. Apple said this could happen if the alloc and init methods are separated and the init method returns a different object than alloc. I checked all of our allocations and they follow the recommended format:
Class *var = [[Class alloc] initMethod:arg];
Has anyone seen an infinite loop of this sort? I have not been able to catch it while using the Xcode debugger, and it is very inconsistent. Since ARC is injecting the retains and releases, I don't have any idea where the crash originates.
Related
I'm trying to debug a crash for which I do not know the cause. Unfortunately, all I have is a stack trace I have retrieved from Crashlytics, and there is little evidence I can find of my app causing this to happen, so unfortunately I cannot provide any concrete code examples, I'm posting here for the sheer hope that someone has run into this before.
I'm seeing in all of the associated crash stack traces I've collected via Crashlytics that it's crashing on a thread titled "com.apple.avkit.seekQueue". The output looks as thus:
Crashed: com.apple.avkit.seekQueue
0 libobjc.A.dylib 0x18c3e17f4 objc_object::release() + 8
1 libsystem_blocks.dylib 0x18c86fa68 _Block_release + 160
2 libdispatch.dylib 0x18c81a9a0 _dispatch_client_callout + 16
3 libdispatch.dylib 0x18c828ad4 _dispatch_queue_serial_drain + 928
4 libdispatch.dylib 0x18c81e2cc _dispatch_queue_invoke + 884
5 libdispatch.dylib 0x18c828fa8 _dispatch_queue_override_invoke + 344
6 libdispatch.dylib 0x18c82aa50 _dispatch_root_queue_drain + 540
7 libdispatch.dylib 0x18c82a7d0 _dispatch_worker_thread3 + 124
8 libsystem_pthread.dylib 0x18ca23100 _pthread_wqthread + 1096
9 libsystem_pthread.dylib 0x18ca22cac start_wqthread + 4
The exception I see thanks to Crashlytics is EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020. From this I can only presume that there is an AVPlayer doing something to a deallocated or restricted memory address, but the stack trace doesn't reveal any other entry points into my app other than main.m in the main thread.
FWIW, Crashlytics also recommends the following:
The stack trace indicates that heap corruption may have caused your
app to crash. Memory corruption can occur pretty easily from freeing a
dangling pointer, a thread race, or bad pointer arithmetic. The
important thing to keep in mind is that the resulting crash may happen
long after the initial corruption. As a result, the stack trace for
this crash might not provide any clues to the location of the bug in
your code.
Having said all that, does anyone have any insight as to what might be causing this, how I can debug this, or even if it might be an issue with AVKit?
I am getting some crash logs in Crashlytics for my iOS app and I am stumped as to how to interpret them. I have tried everything I can think of in my app to create a crash, and have been unable to create one that will result in a stack trace like the following:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x397e6b26 objc_msgSend + 5
1 Foundation 0x2fcc7f8d -[NSError dealloc] + 60
2 libobjc.A.dylib 0x397f6b0b objc_object::sidetable_release(bool) + 174
3 Foundation 0x2fd241f5 -[NSFilesystemItemRemoveOperation dealloc] + 60
4 libobjc.A.dylib 0x397f6b0b objc_object::sidetable_release(bool) + 174
5 libobjc.A.dylib 0x397e8007 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 358
6 CoreFoundation 0x2f2de981 _CFAutoreleasePoolPop + 16
7 UIKit 0x31b1624d _wrapRunLoopWithAutoreleasePoolHandler + 36
8 CoreFoundation 0x2f3761cd __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 20
9 CoreFoundation 0x2f373b71 __CFRunLoopDoObservers + 284
10 CoreFoundation 0x2f373eb3 __CFRunLoopRun + 730
11 CoreFoundation 0x2f2dec27 CFRunLoopRunSpecific + 522
12 CoreFoundation 0x2f2dea0b CFRunLoopRunInMode + 106
13 GraphicsServices 0x34005283 GSEventRunModal + 138
14 UIKit 0x31b82049 UIApplicationMain + 1136
15 Pocket Linesman 0x000d5a8b main + 17 (main.m:17)
Would anyone know how I can go about interpreting the cause of this stack trace? It seems that something is occurring when I am deleting an object in my app from the file system, but I am not 100% sure.
We can see in the backtrace _CFAutoreleasePoolPop.
It means that the crash occurred while the autorelease pool of the current run loop was trying to release an object that was marked for autorelease...
Usually, it means that an autoreleased object was released manually.
Imagine the following:
{
NSObject * o;
o = [ [ [ NSObject alloc ] init ] autorelease ];
[ o release ];
}
The o object here has a retain count of 1, and is marked for autorelease, so the current instance of the autorelease pool will send it a release message next time it's drained.
So the manual call to release, which is wrong, won't produce a crash, as the object is still leaving yet. But the object will then be deallocated, leaving the autorelease pool with a reference to a deallocated object.
When the pool is drained, it will then try to send a release message to that invalid reference, and your app will crash.
By the internal NSFilesystemItemRemoveOperation being deallocated, I would guess that you're dealing with problematic memory management around NSFileManager's removeItemAtPath:error:. Are you making this call anywhere in your code?
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 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?
Is this definitely a memory crash, or should I be looking for something else?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x81093cd0
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x33563f78 objc_msgSend + 16
1 Foundation 0x34d6b92c __NSFireDelayedPerform + 408
2 CoreFoundation 0x35919a2c __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
3 CoreFoundation 0x35919692 __CFRunLoopDoTimer + 358
4 CoreFoundation 0x35918268 __CFRunLoopRun + 1200
5 CoreFoundation 0x3589b49e CFRunLoopRunSpecific + 294
6 CoreFoundation 0x3589b366 CFRunLoopRunInMode + 98
7 GraphicsServices 0x33636432 GSEventRunModal + 130
8 UIKit 0x33073cce UIApplicationMain + 1074
Using the profiler, live bytes are well under 10MB at all times, and when memory warns happen I'm back to 3MB or below.
This statement returns YES, so I assume I have zombies enabled:
getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")
When I'm running from Xcode, the app crashes without Xcode even being aware (after some arbitrary number of memory warns).
Any suggestions besides "run with NSZombies enabled?" And, is this definitely a memory crash?
SIGSEGV happens when the code tries to access memory that "doesn't exist" (that is, the address you are trying to use doesn't have a mapping in your virtual address space).
The exact cause of this can be a large number of things - the most common ones are:
Using pointers that are not (properly) initialized.
Walking off the end of an array.
Using memory that has been freed.
Note that all of the above are examples of "undefined behaviour", so you may well have situations where your code doesn't crash although it's doing something wrong, but the same code, under other circumstances, DOES go wrong.
Yes, this is a memory-related error (segmentation fault). Keep in mind that NSZombies can't catch every memory error.