Command-line Objective-C++ tool has started crashing in [NSApplication sharedApplication]

184 views Asked by At

I have a little CLT for copying and pasting images, written in Objective-C++. Until recently, this program compiled and ran as intended – but only just now, it seems, it has started crashing in the call to [NSApplication sharedApplication].

The stack traces indicate that the crash happens when NSApplication initializes an NSUserDefaults instance, which ends up calling a CFDictionary-related function (i.e. CFDictionarySetValue) which then crashes in free… but from within libjemalloc.

Here’s an example stack trace:

-   Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libjemalloc.2.dylib             0x000000010e7b4ec5 free + 164
1   libjemalloc.2.dylib             0x000000010e7e3d50 zone_free + 168
2   com.apple.CoreFoundation        0x00007fffc5a912c5 __CFBasicHashRehash + 3461
3   com.apple.CoreFoundation        0x00007fffc5a96927 __CFBasicHashAddValue + 103
4   com.apple.CoreFoundation        0x00007fffc5a97a3d CFDictionarySetValue + 221
5   com.apple.CoreFoundation        0x00007fffc5c467da __63-[_CFXPreferences(SearchListAdditions) withSnapshotSearchList:]_block_invoke + 554
6   com.apple.CoreFoundation        0x00007fffc5c4710f -[_CFXPreferences(SearchListAdditions) withSearchLists:] + 79
7   com.apple.CoreFoundation        0x00007fffc5c4655b -[_CFXPreferences(SearchListAdditions) withSnapshotSearchList:] + 155
8   com.apple.CoreFoundation        0x00007fffc5ad08bb __CFXPreferencesCopyCurrentApplicationState + 123
9   com.apple.CoreFoundation        0x00007fffc5ad04dc _CFLocaleCopyCurrentGuts + 268
10  com.apple.CoreFoundation        0x00007fffc5ad0399 +[NSLocale currentLocale] + 9
11  com.apple.Foundation            0x00007fffc7508026 -[NSUserDefaults(NSUserDefaults) init] + 1589
12  com.apple.Foundation            0x00007fffc7507995 +[NSUserDefaults(NSUserDefaults) standardUserDefaults] + 81
13  com.apple.AppKit                0x00007fffc35c9254 +[NSApplication initialize] + 90
14  libobjc.A.dylib                 0x00007fffda9b0b04 CALLING_SOME_+initialize_METHOD + 19
15  libobjc.A.dylib                 0x00007fffda9a16b9 _class_initialize + 579
16  libobjc.A.dylib                 0x00007fffda9a105b lookUpImpOrForward + 240
17  libobjc.A.dylib                 0x00007fffda9a0ad4 _objc_msgSend_uncached + 68
18  impaste                         0x0000000106197198 void objc::run_thread<AXDryRunThread>(NSDictionary*) + 120
19  impaste                         0x0000000106196820 main + 2608
20  libdyld.dylib                   0x00007fffdb294235 start + 1

… This last bit is most curious as I am not using the JeMalloc library. Neither my CLT program nor the libraries on which it is built have anything to do with JeMalloc, and the build system doesn’t currently reference it at all. I don’t include anything from, or link anything to, the JeMalloc library at any point whatsoever.

However: from the stack trace, it looks like the CoreFoundation libraries I am using are, in fact, using JeMalloc.

I don’t know much about JeMalloc, but I do believe that it provides a global drop-in replacement for malloc and free (in addition to furnishing a host of custom, fine-grained memory-management functions).

My call to [NSApplication sharedApplication] (as seen on line #18 of the stack trace above) looks like this:

template <typename OCThreadType> inline
void run_thread(NSDictionary* options = @{}) {
    @autoreleasepool {
        [NSApplication sharedApplication];
        [[[OCThreadType alloc] initWithOptions:options] start];
        AXAppDelegate* delegate = [[AXAppDelegate alloc] init];
        NSApp.delegate = delegate;
        [NSApp run];
    };
}

Can anyone shed some light on this? What could cause this program to crash in this fashion (and specifically, what may have changed recently in CoreFoundation)?

0

There are 0 answers