Strange Crash When Call performSelector on a new NSThread Object

Crash Stack:


Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x0000cdd42a07c738

Thread 97 Name: BDH_Thread:0x2821c7cc0
Thread 97 Crashed: 
0  CoreFoundation                 0x00000001813e3cfc __CFGetNonObjCTypeID +  88
1  CoreFoundation                 0x000000018140896c _CFRunLoopSourceSignal +  28
2  Foundation                     0x0000000182b54484 _performQueueDequeue +  464
3  Foundation                     0x0000000182b3dd9c ___NSThreadPerformPerform +  104
4  CoreFoundation                 0x0000000181476210 ___CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ +  24
5  CoreFoundation                 0x0000000181486238 ___CFRunLoopDoSource0 +  204
6  CoreFoundation                 0x00000001813c963c ___CFRunLoopDoSources0 +  356
7  CoreFoundation                 0x00000001813cea08 ___CFRunLoopRun +  768
3  CoreFoundation                 0x00000001813e1d7c _CFRunLoopRunSpecific +  572
4  CoreFoundation                 0x000000018145c260 _CFRunLoopRun +  60
10 QQ                             0x00000001047810bc -[BDHUploadManager(Private) runRequests](BDHUploadManager+private.mm:41)
7  Foundation                     0x0000000182b66efc ___NSThread__start__ +  792
4  libsystem_pthread.dylib        0x00000001db3873a4 __pthread_start +  116
5  libsystem_pthread.dylib        0x00000001db3859fc _thread_start +  8


Thread 97 crashed with ARM 64 Thread State:
     x0:  0x0000cdd42a07c730    x1: 0x000000019c8800cc    x2: 000000000000000000     x3: 0x0000000000000001
     x4:  0x0000000000000010    x5: 0x0000000000000002    x6: 0x0000000280e3d800     x7: 0x00000000ffffffec
     x8:  0x0000cdd42a07c738    x9: 0x0000000000000013   x10: 0x000000019fb06278    x11: 0x03e700019fb06279
    x12: 0x0000000000dd2980    x13: 0x000021a1f29ce831   x14: 0x0000000000000001    x15: 0x00000001f29ce830
    x16: 0x00000001f29ce830    x17: 0x00000001813d0c80   x18: 000000000000000000    x19: 0x0000cdd42a07c730
    x20: 0x00000001f82d7900    x21: 0x0000000200000003   x22: 0x00000002837e8b70    x23: 0x0000000000000002
    x24: 0x00000002821c7cc0    x25: 000000000000000000   x26: 0x00000001f82d7920    x27: 0x00000002821c7d80
80    fp: 0x000000016d23dbc0    lr: 0x000000018140896c _CFRunLoopSourceSignal +  28
0     pc: 0x00000001813e3cfc __CFGetNonObjCTypeID +  88

The Code:

[self performSelector:@selector(updateBDHConfigThread:)
             onThread:[BDHUploadManager instance].uploadThread
           withObject:dict
        waitUntilDone:NO];
- (NSThread *)uploadThread {
    if (!_uploadThread) {
        _uploadThread = [[NSThread alloc] initWithTarget:self selector:@selector(runRequests) object:nil];
        
        NSString* strThreadName = [NSString stringWithFormat:@"BDH_Thread:%p", _uploadThread];
        [_uploadThread setName:strThreadName];
        [_uploadThread setThreadPriority:0.6];
        [_uploadThread start];
    }
            
    return _uploadThread;
}
- (void)runRequests {
    CFRunLoopSourceContext context = {0, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL};
    CFRunLoopSourceRef source = CFRunLoopSourceCreate(kCFAllocatorDefault, 0, &context);
    CFRunLoopAddSource(CFRunLoopGetCurrent(), source, kCFRunLoopDefaultMode);
    
    while (YES)
    {
        @autoreleasepool
        {
            NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
            CFRunLoopRun();
            [pool release];
        }
    }
}

Initial analysis:

The crash occurs when accessing an address in a x8 register , which should point to a CFRunloopSource object。

The difficulty is that I cannot reproduce it, but there are many reports from online users, so I need help !

The difficulty is that I cannot reproduce it, but there are many reports from online users

Please post the full crash report. See Posting a Crash Report for info on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Those crash reports are both corrupted. For example, in the second one I see this:

Triggered by Thread:  94

but there is no thread 94 in the crash report. Instead I get half of thread 85’s backtrace and then I’m looking at bits of the Binary Images section:

Thread 85 name:
Thread 85:
0   libsystem_kernel.dylib        	0x00000001d1d8ff24 __psynch_cvwait…
1   libsystem_pthread.dylib       	0x000000020b4c0298 _pthread_cond_w…
2   libc++.1.dylib                	0x00000001b30c1328 std::__1::condi…
0x1078f0000 - 0x107947fff dyld arm64e  <74eac11cb88e3d1eacdb56ec661bb4…

Please check whether the original crash report is corrupted or not.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The previously uploaded crash report was truncated, probably because it contained special symbols. This time I will upload it in three parts, please help me to take a look again, thank you!

Crash Report Part2

Thread 68 Crashed:
0   CoreFoundation                	0x0000000191641954 _CFGetNonObjCTypeID + 92 (CFRuntime.c:1034)
1   CoreFoundation                	0x0000000191655714 CFRunLoopSourceSignal + 28 (CFRuntime_Internal.h:118)
2   Foundation                    	0x000000018b9ed85c performQueueDequeue + 488 (NSThread.m:1025)
3   Foundation                    	0x000000018b9807a0 __NSThreadPerformPerform + 88 (NSThread.m:1039)
4   CoreFoundation                	0x0000000191695f34 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CFRunLoop.c:1957)
5   CoreFoundation                	0x00000001916a230c __CFRunLoopDoSource0 + 176 (CFRunLoop.c:2001)
6   CoreFoundation                	0x0000000191626230 __CFRunLoopDoSources0 + 340 (CFRunLoop.c:2046)
7   CoreFoundation                	0x000000019163bb8c __CFRunLoopRun + 836 (CFRunLoop.c:2953)
8   CoreFoundation                	0x0000000191640ec0 CFRunLoopRunSpecific + 612 (CFRunLoop.c:3418)
9   CoreFoundation                	0x0000000191684ce4 CFRunLoopRun + 64 (CFRunLoop.c:3444)
10  Foundation                    	0x000000018b9a05a8 __NSThread__start__ + 716 (NSThread.m:963)
11  libsystem_pthread.dylib       	0x00000001df6526cc _pthread_start + 148 (pthread.c:893)
12  libsystem_pthread.dylib       	0x00000001df651ba4 thread_start + 8 (:-1)

Thread 69 name:
Thread 69:
0   libsystem_kernel.dylib        	0x00000001cef3537c __psynch_cvwait + 8 (:-1)
1   libsystem_pthread.dylib       	0x00000001df65906c _pthread_cond_wait + 1232 (pthread_cond.c:636)
2   libc++.1.dylib                	0x000000019fc55b68 std::__1::condition_variable::__do_timed_wait(std::__1::unique_lock<std::__1::mutex>&, std::__1::chrono::time_point<std::__1::chrono::system_clock, std::__1::chrono::duration<long long, std::__1::r... + 100 (__threading_support:386)
3   QiDianSDK                     	0x0000000107a848f0 0x107904000 + 1575152
4   QiDianSDK                     	0x0000000107a66f6c 0x107904000 + 1453932
5   QiDianSDK                     	0x0000000107a69508 0x107904000 + 1463560
6   QiDianSDK                     	0x0000000107a69680 0x107904000 + 1463936
7   QiDianSDK                     	0x0000000107a68bd8 0x107904000 + 1461208
8   libsystem_pthread.dylib       	0x00000001df6526cc _pthread_start + 148 (pthread.c:893)
9   libsystem_pthread.dylib       	0x00000001df651ba4 thread_start + 8 (:-1)

The previously uploaded crash report was truncated

Please email that to me directly. My address is in my signature. Make sure to reference this thread because I get a lot of email |-:

I was able to reassemble your crash report for the purposes of this thread, but I’d like to get a copy of the original report so that I can work out why DevForums munged it.


Coming back to your original issue, you posted your -runRequests method and it contains a custom run loop source which kinda confused me. This crash is clearly not related to that run loop source. You can see that in your crash report:

Thread 68 Crashed:
0   CoreFoundation … _CFGetNonObjCTypeID + 92 (CFRuntime.c:1034)
1   CoreFoundation … CFRunLoopSourceSignal + 28 (CFRuntime_Internal.h:118)
2   Foundation     … performQueueDequeue + 488 (NSThread.m:1025)
3   Foundation     … __NSThreadPerformPerform + 88 (NSThread.m:1039)
4   CoreFoundation … __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 …

Note how frame 3 is the run loop source perform function, and it clearly shows that this is the source associated with the -performSelectorXxx support in NSThread.

As to why that’s crashing, it’s hard to say. The run loop source that’s being signaled in frame 1 is entirely internal to this NSThread infrastructure, so it’s hard to imagine how it got broken.

Disassembling the code in frame 2 I see this:

(lldb) disas -n CFRunLoopSourceSignal
CoreFoundation`CFRunLoopSourceSignal:
    0x1c32f86e8 <+0>:   pacibsp 
    0x1c32f86ec <+4>:   stp    x22, x21, [sp, #-0x30]!
    0x1c32f86f0 <+8>:   stp    x20, x19, [sp, #0x10]
    0x1c32f86f4 <+12>:  stp    x29, x30, [sp, #0x20]
    0x1c32f86f8 <+16>:  add    x29, sp, #0x20
    0x1c32f86fc <+20>:  mov    x19, x0
    0x1c32f8700 <+24>:  bl     0x1c32e48e8               ; _CFGetNonObjCTypeID
    0x1c32f8704 <+28>:  cmp    x0, #0x2e

The _CFGetNonObjCTypeID call is part of the CF_ASSERT_TYPE macro invocation you can see here in the Swift open source. For this to crash in this way, the incoming run loop source must be bogus. I can’t see any way that can happen.

This is a weird one. My best guess is that you have some sort of memory corruption issue going on and that’s managed to smash the NSThread state. I recommend that you run your app with the standard memory debugging tools to see if they reveal anything interesting.

If not, open a DTS tech support incident so that I, or one of my colleagues, can spend more time digging into it.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Strange Crash When Call performSelector on a new NSThread Object
 
 
Q