0

There is a crash in the application I am working on. The following is the crash log:

Exception Type:  SIGSEGV
Exception Codes: SEGV_MAPERR at 0xf86985380
Crashed Thread:  4

Thread 4 Crashed:
0   libobjc.A.dylib                     0x000000018677b518 objc_release + 16
1   libobjc.A.dylib                     0x000000018677e21c objc_destructInstance + 80
2   libobjc.A.dylib                     0x00000001867879d0 _objc_rootDealloc + 80
3   MyApp                               0x0000000100060670 __destroy_helper_block_e8_32s40s48s56s (NSURLCache+Utils.m:0)
4   libsystem_blocks.dylib              0x00000001d9ce5124 _call_dispose_helpers_excp + 48
5   libsystem_blocks.dylib              0x00000001d9ce4d54 _Block_release + 252
6   Foundation                          0x000000018786f424 -[NSBlockOperation dealloc] + 76
7   libsystem_blocks.dylib              0x00000001d9ce6e2c bool HelperBase<GenericInline>::disposeCapture<(HelperBase<GenericInline>::BlockCaptureKind)3>(unsigned int, unsigned char*) + 68
8   libsystem_blocks.dylib              0x00000001d9ce5a98 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 160
9   libsystem_blocks.dylib              0x00000001d9ce513c _call_dispose_helpers_excp + 72
10  libsystem_blocks.dylib              0x00000001d9ce4d54 _Block_release + 252
11  libdispatch.dylib                   0x0000000194846328 __destroy_helper_block_8_32c35_ZTS29dispatch_block_private_data_s + 96
12  libsystem_blocks.dylib              0x00000001d9ce5124 _call_dispose_helpers_excp + 48
13  libsystem_blocks.dylib              0x00000001d9ce4d54 _Block_release + 252
14  libdispatch.dylib                   0x0000000194845fdc _dispatch_client_callout + 20
15  libdispatch.dylib                   0x000000019484946c _dispatch_continuation_pop + 504
16  libdispatch.dylib                   0x0000000194848ad4 _dispatch_async_redirect_invoke + 584
17  libdispatch.dylib                   0x0000000194857a6c _dispatch_root_queue_drain + 396
18  libdispatch.dylib                   0x0000000194858284 _dispatch_worker_thread2 + 164
19  libsystem_pthread.dylib             0x00000001d9ce8dbc _pthread_wqthread + 228
20  libsystem_pthread.dylib             0x00000001d9ce8b98 start_wqthread + 8

It looks a little bit similar as Objective-C crash on __destroy_helper_block_, but my object holds strong reference of NSOperationQueue and NSOperationBlock as its properties. So they should be different.

And also, I don't quite understand the conclusion of Objective-C crash on __destroy_helper_block_. If it's in ARC (it's a post of 8 years ago, so I can't tell if it's ARC or MRC), how can a released block be released again when the NSOperationQueue is released? Shouldn't the block be automatically copied?

For my case, the only entry in stack trace directly related to my application doesn't tell anything, as the related code is actually dead code of a private category not in use at all. It seems to be result of wild pointer. But how can the case of wild pointer happen in ARC if we don't pass an object as address wrongly? While the crashes with above stack trace happen plenty of times everyday although we can't reproduce it locally.

As I can see, there are some reference issues in my app (using self in block without weakify/strongify). But in the world of ARC, should the wrong usage of self cause cyclic reference and memory leak instead of a crash?

Bill David
  • 63
  • 3
  • The block you pass to your `NSBlockOperation` probably captures a variable that is somehow over-released. When the `NSBlockOperation` is deallocated, it releases its blocks, and those release the captured variables. So check the captured variables involved here. – DarkDust Oct 05 '22 at 13:09
  • Thanks @DarkDust. But how can a variable be over-released in ARC? – Bill David Oct 05 '22 at 13:14
  • Are you _sure_ all involved code is _correct_ ARC? Incorrect owner transfer of CoreFoundation objects can result in crashes, for example (`CFBridgingRelease` vs. `__bridge`). You can enable zombie objects in your scheme (Diagnostics tab) to find out _what_ object is over-released here. – DarkDust Oct 05 '22 at 13:24
  • Thanks @DarkDust. It's a reasonable deduction for over-released object. I tried to enable zombie objects detection and also tried Analyze, but failed to identify any issues. What is still puzzling to me is: why most of crashes happen with `3 MyApp 0x0000000100060670 __destroy_helper_block_e8_32s40s48s56s (NSURLCache+Utils.m:0)` which is actually dead code not called at all (although I can also see crash with obj_msgSend or objc_release without above trace)? – Bill David Oct 08 '22 at 00:02
  • I have also tried with `NSError *error; @autoreleasepool { CFStringRef domain = CFStringCreateWithCString(NULL, "dummy-domain", kCFStringEncodingMacRoman); CFErrorRef cfError = CFErrorCreate(kCFAllocatorDefault, domain, 100, NULL); error = (__bridge NSError *)cfError; CFRelease(cfError); } dispatch_queue_t concurrent = dispatch_queue_create("concurrent", DISPATCH_QUEUE_CONCURRENT); for (int i = 0; i < 100; i++) { dispatch_async(concurrent, ^{ sleep(1); NSLog(@"<< – Bill David Oct 08 '22 at 00:11

0 Answers0