I noticed a function named block_destroy_helper in this crash log from my iOS app. I want to know more what is this function, but I can't find any useful information. I just want to know the followings:
What is this function doing?
What event can trigger a call to this function?
When I reproduce this crash on Debug build, this crash was an index out of bound error in my own source code. How could this error turned into block_destroy_helper in Release build?
For crash log below, MyModule is a module in my app written in Swift. MyModule uses another library AsyncDisplayKit written in Objective-C.
Crashed: com.apple.main-thread
EXC_BREAKPOINT 0x0000000106d5e7ec
Crashed: com.apple.main-thread
0 MyModule 0x967ec block_destroy_helper.26 + 5740
1 MyModule 0x97048 block_destroy_helper.26 + 7880
2 AsyncDisplayKit 0x2ee28 -[ASCollectionView collectionView:didSelectItemAtIndexPath:] + 208
3 UIKitCore 0x3006e0 -[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:performCustomSelectionAction:] + 816
4 UIKitCore 0x54c4d4 -[UICollectionView touchesEnded:withEvent:] + 480
UPDATE
Finally, I can reproduce the crash. But when I reproduce this crash on Debug build, the crash was from my code, and was an Array index out of bound error (as shown below).
Crashed: com.apple.main-thread
0 libswiftCore.dylib 0x32cb4 closure #1 in closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 356
1 libswiftCore.dylib 0x32a1c closure #1 in closure #1 in _assertionFailure(_:_:file:line:flags:) + 192
2 libswiftCore.dylib 0x323bc _assertionFailure(_:_:file:line:flags:) + 228
3 libswiftCore.dylib 0x12274 _ContiguousArrayBuffer.capacity.getter + 274
4 libswiftCore.dylib 0x15d14 Array.subscript.getter + 84
5 MyModule 0x135d08 $s9MyModule16HomeMenuListNodeC010collectionF0_15didSelectItemAtySo012ASCollectionF0C_10Foundation9IndexPathVtF + 872
6 MyModule 0x137d64 $s9MyModule16HomeMenuListNodeC010collectionF0_15didSelectItemAtySo012ASCollectionF0C_10Foundation9IndexPathVtFTo + 136
7 AsyncDisplayKit 0x763a4 -[ASCollectionView collectionView:didSelectItemAtIndexPath:] + 272
8 UIKitCore 0x2f2c64 -[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:performCustomSelectionAction:] + 1020
9 UIKitCore 0x666864 -[UICollectionView touchesEnded:withEvent:] + 612
Related
I use AudioEngine.
In crash reports I see some random EXC_BREAKPOINT crashes with this stacktrace
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001896df0e4
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [12467]
Triggered by Thread: 15
Thread 15 Crashed:
0 libdispatch.dylib 0x00000001896df0e4 __DISPATCH_WAIT_FOR_QUEUE__ + 448 (queue.c:1619)
1 libdispatch.dylib 0x00000001896dec74 _dispatch_sync_f_slow + 140 (queue.c:1732)
2 libdispatch.dylib 0x00000001896dec74 _dispatch_sync_f_slow + 140 (queue.c:1732)
3 AVFAudio 0x00000001965b11a8 -[AVAudioEngine dealloc] + 308 (AVAudioEngine.mm:406)
4 Foundation 0x0000000189ce52ac -[NSConcreteNotification dealloc] + 68 (NSNotification.m:206)
5 AVFAudio 0x00000001965b7158 invocation function for block in AVAudioEngineImpl::IOUnitConfigurationChanged() + 292 (AVAudioEngine.mm:1215)
6 libdispatch.dylib 0x00000001896de998 _dispatch_block_async_invoke2 + 104 (queue.c:525)
7 libdispatch.dylib 0x00000001896fb184 _dispatch_client_callout + 16 (object.m:495)
8 libdispatch.dylib 0x00000001896d4e8c _dispatch_continuation_pop$VARIANT$armv81 + 404 (inline_internal.h:2484)
9 libdispatch.dylib 0x00000001896e502c _dispatch_source_invoke$VARIANT$armv81 + 1232 (source.c:568)
10 libdispatch.dylib 0x00000001896d85e0 _dispatch_lane_serial_drain$VARIANT$armv81 + 260 (inline_internal.h:2525)
11 libdispatch.dylib 0x00000001896d9128 _dispatch_lane_invoke$VARIANT$armv81 + 400 (queue.c:3863)
12 libdispatch.dylib 0x00000001896e243c _dispatch_workloop_worker_thread + 576 (queue.c:6445)
13 libsystem_pthread.dylib 0x000000018974ab88 _pthread_wqthread + 276 (pthread.c:2351)
14 libsystem_pthread.dylib 0x000000018974d760 start_wqthread + 8
I can't reproduce this crash and stacktrace doesn't point to my code. Does anyone know what is cause of this crash, how this can be fixed and if it's even possible to fix?
Thanks
According to the apple documentation of AVAudioEngineConfigurationChange,
You must not release the engine during handling this notification.
Note The engine must not be deallocated from within the client's
notification handler. Callback happens on an internal dispatch queue
and can deadlock while trying to teardown the engine synchronously.
Though you didn't release at that time, It can be caused.
AVAudioEngine in iOS 11 or 12 can be stucked to notify before, then you release engine later.
There's workaround. You have to re-use the audio engine rather than re-create.
I'm new to this project and Firebase has been added only recently, so I've some issue to figure out the reason of a crash (that I can't reproduce locally).
It's a EXC_BAD_ACCESS KERN_INVALID_ADDRESS on dispatch_call_block_and_release.
Therefore it should be a memory issue, trying to access to an object that has been already deallocated.
The last traced line is an addObserver call of Notification Center, and then the call trace continue with several calls but not showing an exact line of code. Since I don't see anything wrong with that observer, I'm wondering: is this line significant? Or it could be that the app is crashing on a different thread so that the call trace is irrelevant?
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008
Crashed: com.apple.main-thread
0 MyPod 0x103dafb18 (Missing)
1 MyPod 0x103daf564 (Missing)
2 MyPod 0x103daf9fc (Missing)
3 MyApp 0x103b12ffc (Missing)
4 MyPod 0x103daf268 (Missing)
5 MyPod 0x103dae844 (Missing)
6 MyPod 0x103daef64 (Missing)
7 MyPodClient 0x103d40fd0 (Missing)
8 MyPodClient 0x103d3dcb8 (Missing)
9 libdispatch.dylib 0x1a9e38610 _dispatch_call_block_and_release + 24
10 libdispatch.dylib 0x1a9e39184 _dispatch_client_callout + 16
11 libdispatch.dylib 0x1a9deb190 _dispatch_main_queue_callback_4CF$VARIANT$mp + 1044
12 CoreFoundation 0x1aa0ea5e4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
13 CoreFoundation 0x1aa0e55d8 __CFRunLoopRun + 2004
14 CoreFoundation 0x1aa0e4adc CFRunLoopRunSpecific + 464
15 GraphicsServices 0x1b406a328 GSEventRunModal + 104
16 UIKitCore 0x1ae1dfae0 UIApplicationMain + 1936
17 MyApp 0x102e0bce0 main + 21 (PlayerPlugin.swift:21) //-> This is the line in which a func is called, and inside this func observers are added.
thanks
ps. I don't know if this helps, but for some crash reports (but not all of them), I get in the KEYS section this line:
crash_info_entry_0
CoreUI: deallocating _CUIInternalLinkRendition 7113 /private/var/containers/Bundle/Application/A6721767-C6DD-43AB-B2E0-094D4CBD12D6/MyApp.app/Assets.car
Is this related to assets? However it looks more like a consequence of the crash, rather than a cause.
i have such a report from Crashlytics:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x000000019503fbd0 objc_msgSend + 16
1 CoreFoundation 0x00000001836e5458 CFRelease + 524
2 CoreFoundation 0x00000001836f1a18 -[__NSArrayM dealloc] + 152
3 libobjc.A.dylib 0x0000000195045724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
4 CoreFoundation 0x00000001836e9074 _CFAutoreleasePoolPop + 28
5 Foundation 0x000000018461a588 -[NSAutoreleasePool release] + 148
6 UIKit 0x00000001882b4460 -[UIApplication _run] + 588
7 UIKit 0x00000001882aefac UIApplicationMain + 1488
Is there anything I can do to catch such an issue? It happens on customer devices so I have no chance to reproduce it.
For crashes like this one, if the crash is reproducible, turn on NSZombies in your project's environment variables. This will keep deallocated objects alive (zombies) and when one of them is messaged, the caller and message will be captured on the crashing object.
Turn it off when done as it can block the memory of the app due to the objects not being released for zombie tracking.
Some of logic code need to be run in background. You need to try debug where is code is error and then add this code
DispatchQueue.main.async(execute: {
// your code
})
It's been answered here: objc_msgSend [__NSArrayM dealloc] crash report sometimes from Crashlytics
Basically, upgrade your Crashlytics framework to past 3.0.9. The crash was in the crash reporting framework itself.
I am wondering if there is anything in the following stack trace that I received from Crashlytics that I should be concerned about:
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x000000007becbeb8
Thread : Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x3a3c61fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3a42fa33 pthread_kill + 58
2 libsystem_c.dylib 0x3a376ffd abort + 76
3 libc++abi.dylib 0x396a5cd7 abort_message + 74
4 libc++abi.dylib 0x396be6e5 default_terminate_handler() + 252
5 libobjc.A.dylib 0x39e07921 _objc_terminate() + 192
6 libc++abi.dylib 0x396bc1c7 std::__terminate(void (*)()) + 78
7 libc++abi.dylib 0x396bbd2d __cxa_increment_exception_refcount
8 libobjc.A.dylib 0x39e077f7 objc_exception_rethrow + 42
9 CoreFoundation 0x2f499c9d CFRunLoopRunSpecific + 640
10 CoreFoundation 0x2f499a0b CFRunLoopRunInMode + 106
11 GraphicsServices 0x3419a283 GSEventRunModal + 138
12 UIKit 0x31d3d049 UIApplicationMain + 1136
13 Pocket Linesman 0x0005aa8b main + 17 (main.m:17)
From my searching around the internet, I am unable to find an example of where this type of crash has an actionable fix for it. Also, I am completely unable to reproduce a crash like this through a normal interaction in my app.
Does this stack trace indicate a normal crash due to low memory issues on the user's iOS device, or something more?
This is my first app using Crashlytics, so i am still learning how to read the reports it sends me.
Thanks!
The original source of the crash is an uncaught exception. The original exception was caught and rethrown from CFRunLoopRunSpecific(). That has obscured the original source of the exception in the backtrace. Sometimes, the exception details are logged and they might indicate the original backtrace. Do you have any log messages that may have been written at the same time?
I was running into the same issue whenever the crash was caused by UI code.
Have you set NSSetUncaughtExceptionHandler in your app delegate by any chance? Setting mine caused me to get the useless pthread_kill message.
Unsetting mine in distributed builds allowed me to get more useful crash reporting from the same error.
Hope this helps :)
I've been getting some low level crashes lately, and this one in particular is hard to determine the origin / state of the app. Has anyone seen this or know the problem? Thanks!
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x3dcccccd
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x000025fa objc_msgSend + 18
1 UIKit 0x00162d1c -[UIAlertView(Private) _performPopup:] + 12
2 UIKit 0x001628de -[UIAlertView(Private) _repopup] + 10
3 UIKit 0x0016d196 -[UIAlertView(Private) _removeAlertWindowOrShowAnOldAlert] + 70
4 UIKit 0x00162afa -[UIAlertView(Private) _popoutAnimationDidStop:finished:] + 502
5 UIKit 0x00050ae4 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 184
6 UIKit 0x000509ee -[UIViewAnimationState animationDidStop:finished:] + 34
7 QuartzCore 0x0002ee8c run_animation_callbacks(double, void*) + 284
8 QuartzCore 0x0002ed2c CA::timer_callback(__CFRunLoopTimer*, void*) + 96
9 CoreFoundation 0x00022d1c CFRunLoopRunSpecific + 2092
10 CoreFoundation 0x000224da CFRunLoopRunInMode + 42
11 GraphicsServices 0x000030d4 GSEventRunModal + 108
12 GraphicsServices 0x00003180 GSEventRun + 56
13 UIKit 0x0000342a -[UIApplication _run] + 374
14 UIKit 0x00001954 UIApplicationMain + 636
15 iPadDrinkHub.1.0.7 0x00002f24 0x1000 + 7972
16 iPadDrinkHub.1.0.7 0x00002ed8 0x1000 + 7896
Weird crashes are sometimes a symptom of memory corruption and/or mismanagement. I just found and fixed a difficult-to-find bug in one of my apps a few days ago. The app had been working flawlessly for 6 months on iOS 3.2, but would crash instantly on iOS 4.2. The crash was happening while adding the main view to the window during applicationDidFinishLaunching. The stack trace showed 100% iOS code; there wasn't a single function of mine in there anywhere (except for applicationDidFinishLaunching). It turned out I was over-releasing a UIImage in code that had been called earlier while views were getting loaded. (I was mistakenly calling release on an autoreleased UIImage).
I haven't seen the specific crash that you're seeing, but here are a few things you can try that may shed some light:
(1) Run the app with NSZombieEnabled. This is an environment variable you set via Xcode that will often identify places where you may be referencing objects that have already been freed (e.g., like the over-release example I mentioned earlier). Additional details are here:
http://www.cocoadev.com/index.pl?NSZombieEnabled
(2) You can turn on logging that will log all messages sent to all objects. The log is a written to a text file in the tmp folder. If you inspect the log file leading up to the crash, you may gain some insight into what's happening right before the crash. This is actually the technique I used to solve my bug. You can either modify your code to enable/disable logging:
instrumentObjcMessageSends(YES);
// Do stuff...
instrumentObjcMessageSends(NO);
Or, you can call the function directly from the debugger. For example, set a breakpoint right before the crash, then drop into the debugger console and do this:
(gdb) call (void)instrumentObjcMessageSends(YES)
Additional details are here:
http://www.dribin.org/dave/blog/archives/2006/04/22/tracing_objc/