I just upgraded one of my apps to Swift 5, I didn't change so much at all and there didn't seem to be any problems, so I just released it in production (fortunately in phased release).
After 1 days I started to see a very strange crash on Crashlytics that affect the 15% of people that is using my app.
This is the stack trace:
Crashed: com.apple.main-thread
0 (Missing) 0x31698aa1503e0 (Missing)
1 libswiftCore.dylib 0x1afa5ac68 _swift_release_dealloc + 28
2 App 0x104194c3c outlined consume of MyModel? + 4300033084
3 App 0x104482cb8 #objc MyController.__ivar_destroyer (<compiler-generated>)
4 libobjc.A.dylib 0x180f267cc object_cxxDestructFromClass(objc_object*, objc_class*) + 148
5 libobjc.A.dylib 0x180f366b8 objc_destructInstance + 68
6 libobjc.A.dylib 0x180f36720 object_dispose + 16
7 UIKitCore 0x1ae2edac0 -[UIResponder dealloc] + 152
8 UIKitCore 0x1add173e0 -[UIViewController dealloc] + 1748
9 App 0x10431d82c BaseViewController.__deallocating_deinit (MyController.swift:56)
10 App 0x10431d85c #objc BaseViewController.__deallocating_deinit (<compiler-generated>)
11 libobjc.A.dylib 0x180f41b9c (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 672
12 CoreFoundation 0x181d59f40 _CFAutoreleasePoolPop + 28
13 CoreFoundation 0x181cd8e00 __CFRunLoopRun + 1932
14 CoreFoundation 0x181cd8354 CFRunLoopRunSpecific + 436
15 GraphicsServices 0x183ed879c GSEventRunModal + 104
16 UIKitCore 0x1ae2c3b68 UIApplicationMain + 212
17 App 0x104108468 main (AppDelegate.swift:21)
18 libdyld.dylib 0x18179e8e0 start + 4
I searched already something on the web but I find only a thread on the Swift Forum not very related to this.
MyModel is actually a struct model that is nested into another Model.
MyController is the very huge controller that manages the model.
The crash seems to happen obviously when popping the controller and so when the System tries to deallocate all the related properties.
I tried to replicate it many times with no results, and I didn't know really where to start looking.
Someone had the same problem?
UPDATE [Partially Fixed]:
It seemed to be a stack corruption caused by a Advertising Framework, to fix this I moved MyModel from Struct to Class, it's now on the Heap and can't get double freed.
From my experience, most of the outlined consume of errors are caused by concurrency issue. When one queue/thread reading the struct while another queue/thread modifying it without synchronization (mutex, semaphore, barrier, etc).
You need to check all threads stacks to see which thread access MyModel simultaneously with the Main(crashed) thread.
Related
I'm finding that after my app has been in the background for a while, (half hour + maybe) it crashes immediately on resume.
Crash log reveals that it is EXC_BAD_ACCESS, but I'm at loss for how to debug this one, because I don't know what gets released when my app goes to background (for a long time in particular). (Exception codes are 0x0000000 repeated)
Is there any documentation on this / can anyone give insight about what they did to fix this in the past?
While we're at it, is there a way to test this without waiting for hours before each try? Some way to simulate whatever it is that is happening to my app?
Thanks
Update
I just read a bit more closely, and there's something here about a timer, I added some stuff that uses timers recently to my app, could this give more info? (See item 12)
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x32858a1c __pthread_kill + 8
1 libsystem_c.dylib 0x337013b4 pthread_kill + 52
2 libsystem_c.dylib 0x336f9bf8 abort + 72
3 libstdc++.6.dylib 0x30504a64 __gnu_cxx::__verbose_terminate_handler() + 376
4 libobjc.A.dylib 0x3068f06c _objc_terminate + 104
5 libstdc++.6.dylib 0x30502e36 __cxxabiv1::__terminate(void (*)()) + 46
6 libstdc++.6.dylib 0x30502e8a std::terminate() + 10
7 libstdc++.6.dylib 0x30502f5a __cxa_throw + 78
8 libobjc.A.dylib 0x3068dc84 objc_exception_throw + 64
9 MarsCrash 0x0000be88 0x1000 + 44680
10 MarsCrash 0x00020646 0x1000 + 128582
11 Foundation 0x327196ce __NSFireDelayedPerform + 362
12 CoreFoundation 0x334e7a40 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
13 CoreFoundation 0x334e9ec4 __CFRunLoopDoTimer + 844
14 CoreFoundation 0x334ea83e __CFRunLoopRun + 1082
15 CoreFoundation 0x3347aebc CFRunLoopRunSpecific + 224
16 CoreFoundation 0x3347adc4 CFRunLoopRunInMode + 52
17 GraphicsServices 0x311a5418 GSEventRunModal + 108
18 GraphicsServices 0x311a54c4 GSEventRun + 56
19 UIKit 0x31b90d62 -[UIApplication _run] + 398
20 UIKit 0x31b8e800 UIApplicationMain + 664
21 MarsCrash 0x00002558 0x1000 + 5464
22 MarsCrash 0x00002500 0x1000 + 5376
Common case for such situations is a call to an object that was released due to low memory warnings. EXEC_BAD_ACCESS — accessing to over-release object according to Apple's source (http://developer.apple.com/library/mac/#qa/qa1367/) You can find an actual source of the problem by taking a crash logs from your device and symbolizing it to an actual code strings in your product. I assume that knowing the class and method and code line number will give you a preliminary understanding what goes wrong in your code. Please, review following apple's article to understand further details — http://developer.apple.com/library/ios/#technotes/tn2151/_index.html
For an advanced topics on debugging following link maybe also very useful — http://developer.apple.com/library/ios/#technotes/tn2239/_index.html Actually Apple provides a ton of difference ways to debug such type of an issue.
If it is indeed caused by a memory hit, you can try running it on the simulator, which has a menu item which lets you send your app a simulated memory warning. Your app will try to do all the things it does during a real memory warning, and that might help you find your bug. Also, look at running with NSZombies enabled You might want to check out this page -- I find it very helpful:
http://www.cocoadev.com/index.pl?DebuggingAutorelease
Just spent some time... on a crash, without understanding it. That's a classic:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010
Which leads me to a memory issue, addressing the invalid adress 0x10
What bothers me is that I have crash report and stack trace, which differ:
The crash report, sent by user (symbolicated successfully, that happens) :
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
The crash stack trace (catched live 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 differ, and the stack trace points to the crash in my code, but at addresses I can neither symbolicate nor identify. I think the crash report indicates that a message was sent to a released instance... Probably related to the use of :
+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selector
So here (finally!) are my questions:
What explains the differences between logs? (libobjc.A vs libSystem.B ??)
Does the SIGBUS comes from my code or from UIKit?
How can I decipher the stack trace upper addresses (0x000d79??, which atos doesn't resolve)
Is that what I think, an issue related to an animation failing to end? similar to this > How to unset delegate on UIView setAnimationDelegate: call?
AFAIK, setAnimationDelegate is supposed to retain delegate... Someone to confirm?
EDIT: I can't use NSZombiesEnabled, this is a crash report from a published app, a crash that I didn't manage to reproduce on development environment. I just have these logs to diagnose.
Whenever I see objc_msgSend at the top, my trust of the remaining stack is low, as the error that gives this tends to do bad things to the stack.
GuardMalloc is good for this since the attempt to do anything with deallocated space will crash the app immediately in the debugger. The stack will be intact. (This makes the app very slow, but it is a very powerful tool.)
The two stacks are the same up to the UIViewAnimationState method call. The version that came from your exception handler is showing C++ mangled names instead of the regular names shown in the crash log.
(As I understand it) _sigtramp is the system's method of calling your signal handler and is short for Signal Trampoline. The stack entries beyond that are probably your signal-handler code.
Answering my own question, weeks laters, since I had no relevant answers, most are guesses, I wished I had more precise answers, but I guess my question was unclear :
Difference is coming from the origin of the log, a sighandler vs CrashReporter service, which are happening at different times, then the stack traces are slightly different.
SIGBUS comes from UIKit, but chances are big that's on a callback initiated from my code that ends on a released object. These kind of stack traces are a pain to debug when you can't reproduce the issue, since it basically tells you "I'm crashing somewhere because of an animation", which one, where... I still didn't figured precisely. Could be anywhere, and also could be an Apple iOS bug.
The first addresses in the stack are just a dead-end where any SIGBUS stack-trace ends when a released object is called. They differs across compilations (versions), but are the same on any device, That's why they can't be symbolicated. (I would love to have a technical explanation of this, instead of my guess)
& 5. I guess I solved this bug byt being more "agressive" on canceling animations in certain cases like on deallocation of some Views...
Hope that helps someone.
You should try NSZombie, to get information about what object you've released. This is a very useful tool when you get EXC_BAD_ACCESS.
To activate NSZombie do the following:
Get info of the executable.
Go to the arguments tab.
In the "Variables to be set in the environment:" section add:
Name: NSZombieEnabled
Value: YES
Then run your app as usual and when it crashes it should tell you which deallocated object received the message.
1. I'm not 100% sure but I think the discrepancy is due to how the application is being run. In the second log it looks like you're running the application via XCode in debug mode, a sigtramp signal has been sent to indicate a EXC_BAD_ACCESS error.
2. Your code - the error may come from the UIKit library but it's a result of a problem with your usage.
3. This is where NSZombieEnabled will make your life a lot easier! If you run your application with the NSZombieEnabled flag set XCode will keep 'zombie' objects in place of deallocated objects. When a zombie object is sent a message the process will trap the error and let you know exactly what object was sent the message.
If you're using XCode 4 enable NSZombieEnabled using the following instructions...
How do I set up NSZombieEnabled in Xcode 4?
For older versions follow these instructions...
http://www.cocoadev.com/index.pl?NSZombieEnabled
4. It does indeed appear that your animation delegate has been deallocated prior to the animation completing.
Hey Guys,
I know there are about 100.000 thread about EXC_BAD_ACCESS (SIGSEGV) Errors. But no one helped me out. I'm not able to solve my problem myself.
A few hours ago, I duplicated the target of my Xcode Project (a iPhone game) to make a free version. But since this Point I get very strange errors. Sometimes the app works as if nothing happened. But most of the time, I get errors like this:
Running pass 'X86 DAG->DAG Instruction Selection' on function '#gleLLVMVecPrimMultiRender13'
And the stack looks like this:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x015c6c6f prepareForMethodLookup + 31
1 libobjc.A.dylib 0x015c06ad lookUpMethod + 86
2 libobjc.A.dylib 0x015c081a _class_lookupMethodAndLoadCache + 40
3 libobjc.A.dylib 0x015ceaa3 objc_msgSend + 87
4 Birdy Free 0x0001b46d -[SMApplicationManager dealloc] + 58 (SMApplicationManager.m:226)
5 Foundation 0x00489257 -[NSURLConnection(NSURLConnectionReallyInternal) releaseDelegate] + 57
6 Foundation 0x004891f9 _NSURLConnectionReleaseClient + 68
7 CFNetwork 0x01a45742 ClientContextHolder<CFURLConnectionClient_V4>::forget() + 48
8 CFNetwork 0x01a3beee URLConnectionClient::processEvents() + 278
9 CFNetwork 0x01a3bcb7 MultiplexerSource::perform() + 251
10 CoreFoundation 0x0144e01f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
11 CoreFoundation 0x013ac28b __CFRunLoopDoSources0 + 571
12 CoreFoundation 0x013ab786 __CFRunLoopRun + 470
13 CoreFoundation 0x013ab240 CFRunLoopRunSpecific + 208
14 CoreFoundation 0x013ab161 CFRunLoopRunInMode + 97
15 GraphicsServices 0x02a13268 GSEventRunModal + 217
16 GraphicsServices 0x02a1332d GSEventRun + 115
17 UIKit 0x0086d42e UIApplicationMain + 1160
18 Birdy Free 0x000024a0 main + 82 (main.m:13)
19 Birdy Free 0x00002445 start + 53
But the method called is not always the same. In this case it was [SMApplicationManager dealloc] and a few minutes ago it was [CCNode draw]. I can't get the source of this error. I think it has something to do with the second target.
Do any of you guys know anything more?
Sandro Meier
It's weird i got this error, and i went through countless solutions. Turned out, i had duplicated a line of code by accident. Just make sure when you duplicated, there is not code interfering with each other.
Finally after a few more hours of frustrating experiments I found the solution. The whole thing hadn't to anything with the second target. The Problem was the NSURLConnectionDelegate. In this class I implemented a Property named appID. And in one of the methods of the class, I set the variable without the setter. So I placed an autoreleased object at the position of a property. This one get released and the pointer to the variable gets invalid. As soon as the Delegate was released, a Method was sent to this yet released object.
But I can't explain why there appears this strange error Method. I haven't seen anything like that before. Can someone tell my why the error is called
Running pass 'X86 DAG->DAG Instruction Selection' on function '#gleLLVMVecPrimMultiRender13'?
Sandro Meier
`
I've got a stack trace showing a crash responding to a memory warning:
Thu Oct 28 00:42:55 iPhone DTMobileIS[10853] : _memoryNotification : {name = (null), num = 1}
Thu Oct 28 00:42:55 iPhone DTMobileIS[10853] : _memoryNotification : {
OSMemoryNotificationLevel = 1;
timestamp = "2010-10-28 07:42:55 GMT";
}
Thu Oct 28 00:42:55 iPhone MyApp[11059] : Received memory warning. Level=1
Thu Oct 28 00:42:55 iPhone MyApp[11059] : -[__NSCFType tryLock]: unrecognized selector sent to instance 0x41bfd0
Thu Oct 28 00:42:55 iPhone MyApp[11059] : *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFType tryLock]: unrecognized selector sent to instance 0x41bfd0'
*** Call stack at first throw:
(
0 CoreFoundation 0x30897ed3 __exceptionPreprocess + 114
1 libobjc.A.dylib 0x3002f811 objc_exception_throw + 24
2 CoreFoundation 0x30899683 -[NSObject(NSObject) doesNotRecognizeSelector:] + 102
3 CoreFoundation 0x308411d9 ___forwarding___ + 508
4 CoreFoundation 0x30840f90 _CF_forwarding_prep_0 + 48
5 CoreData 0x316cc261 -[_NSSQLCoreConnectionObsever _purgeCaches:] + 124
6 Foundation 0x349bb6b3 _nsnote_callback + 142
7 CoreFoundation 0x3081e713 __CFXNotificationPost_old + 402
8 CoreFoundation 0x3081e3b3 _CFXNotificationPostNotification + 118
9 Foundation 0x349aadb7 -[NSNotificationCenter postNotificationName:object:userInfo:] + 70
10 Foundation 0x349b42d1 -[NSNotificationCenter postNotificationName:object:] + 24
11 UIKit 0x31ed9431 -[UIApplication _performMemoryWarning] + 48
12 UIKit 0x31ec7383 -[UIApplication _receivedMemoryNotification] + 126
13 UIKit 0x31ec72c7 _memoryStatusChanged + 42
14 CoreFoundation 0x3084e825 __CFNotificationCenterDarwinCallBack + 24
15 CoreFoundation 0x30835313 __CFMachPortPerform + 210
16 CoreFoundation 0x3082cce3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 26
17 CoreFoundation 0x3082cca7 __CFRunLoopDoSource1 + 166
18 CoreFoundation 0x3081f56d __CFRunLoopRun + 520
19 CoreFoundation 0x3081f277 CFRunLoopRunSpecific + 230
20 CoreFoundation 0x3081f17f CFRunLoopRunInMode + 58
21 GraphicsServices 0x31e445f3 GSEventRunModal + 114
22 GraphicsServices 0x31e4469f GSEventRun + 62
23 UIKit 0x31e51123 -[UIApplication _run] + 402
24 UIKit 0x31e4f12f UIApplicationMain + 670
25 MyApp 0x00052c81 main + 72
26 MyApp 0x00002f18 start + 52
)
I'm not really sure what core data was doing that it tried to obtain a lock from this object, however I feel like this is indicative of a threading issue somewhere inside my code.
Can anyone think of a good way to debug this or possible root causes?
I ran into this recently and found a solution. The bug is in Core Data itself, and manifests in versions prior to iOS 5.1 (it appears to be fixed in that version).
The crash happens when the persistent store coordinator (PSC) fails to load a given persistent store (say because the schema changed). In this case, the failed store still appears to be added to an internal Core Data cache, even though there is no external access to it. This cache is then flushed automatically by Core Data when the app is backgrounded, or in certain memory pressure situations. Everything is fine unless you the PSC that was used to try to load the failed store has since been deallocated, in which case the cache will try to access it and give the above error.
So, to summarize, you will hit this error in this situation:
Try and fail to load a persistent store from disk. This will likely happen because you've upgraded your app and the model schema changed.
Deallocate the persistent store coordinator you used to to try to load the store.
Background the app, or in some cases trigger a memory warning.
Crash
To work around this problem there are two options. I chose to simply not deallocate the PSC in the case of a failed call to -addPersistentStoreWithType:configuration:URL:options:error:, in which case the cache purge will still access a valid PSC. An alternative is to preemptively check that the model schema matches the on-disk persistent store's scheme using the following two calls:
+[NSPersistentStore metadataForPersistentStoreWithURL:error:]
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
The second solution may avoid leaking a PSC in certain rare cases, but also assumes that the only possible way that a persistent store will fail to load is because of mismatched model schemas.
I actually found, after a bit of code analysis, the root cause of this appears to be crossing threads with CoreData. I had a background thread from an operation queue manipulating a NSManagedObjectContext which originated on the main thread (and caused a save! ouch!).
After a few of these manipulations if I sent a memory warning in the simulator the app would crash.
I am getting an interesting crash that I can never seem to replicate on the simulator:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x3212e86c 0x3212c000 + 10348
1 StockTwits 0x00016b06 0x1000 + 88838
2 Foundation 0x30718422 0x306db000 + 250914
3 Foundation 0x307183a4 0x306db000 + 250788
4 CFNetwork 0x30933e74 0x30923000 + 69236
5 CFNetwork 0x30927b70 0x30923000 + 19312
6 CFNetwork 0x30927e62 0x30923000 + 20066
7 CFNetwork 0x30927a60 0x30923000 + 19040
8 CFNetwork 0x30927a12 0x30923000 + 18962
9 CFNetwork 0x30927990 0x30923000 + 18832
10 CFNetwork 0x3092790e 0x30923000 + 18702
11 CoreFoundation 0x30352a86 0x302e1000 + 465542
12 CoreFoundation 0x30354768 0x302e1000 + 472936
13 CoreFoundation 0x30355504 0x302e1000 + 476420
14 CoreFoundation 0x302fe8e4 0x302e1000 + 121060
15 CoreFoundation 0x302fe7ec 0x302e1000 + 120812
16 GraphicsServices 0x31a776e8 0x31a74000 + 14056
17 GraphicsServices 0x31a77794 0x31a74000 + 14228
18 UIKit 0x323272a0 0x32321000 + 25248
19 UIKit 0x32325e10 0x32321000 + 19984
20 StockTwits 0x00002fd4 0x1000 + 8148
21 StockTwits 0x00002fa4 0x1000 + 8100
I have NSZombies enabled as well as stack logging. Ran through the static analyzer to make sure all objects are retained and released properly, though I have a feeling it is still related to retain/releasing.
Thoughts?
You must be dereferencing a NULL pointer, other than this crash does not happen. The Static Analyzer is a nice tool for getting hints on things you're doing wrong. However, it not finding an error does not mean that your program is bug-free. Also turning on zombies does not always help. Sometimes it's just a simple little oversight.
The fact the simulator does not show this problem doesn't say too much. In the end it's a different machine with a different processor and a different architecture. There are occasions where false code runs well on one platform but crashes on the other.
You should re-symbolicate you stack trace and have a close look at that function it's crashing in. If you want more help it's probably best to post some of the code here.
One more hint: these issues are often spread over multiple methods. The analyzer only sees one method at a time. You should have a look at what happened to the objects in your crashing method BEFORE it was entered.