Hello,
I'm trying to simulate miscellaneous crashes to test my handlers. Things works as expected with NSException and C++ exceptions, however I cannot find a way to trig a C signal.
I tried with this code:
NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:@"com.myCompany.myApp"];
NSRunningApplication *app = runningApplications[0];
UInt32 pid = [app processIdentifier];
kill(pid, SIGABRT);
It is caught by my handler, but it doesn't crash the app (although it's detached from the debugger), I can even continue using the app normally.
I'm wondering if this could be related to something wrong in my handler (especially on how it ends):
signal(sig, SIG_IGN);
dispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, sig, 0, dispatch_get_global_queue(0, 0));
dispatch_source_set_event_handler(source, ^{
// I write some logs on disk here, then uninstall the handlers associated with this or that signal:
for(int i=0; i<SignalSourceCount; i++) {
if (_signalSources[i]) {
dispatch_source_cancel(_signalSources[i]);
_signalSources[i] = NULL;
}
}
});
dispatch_resume(source);
I've seen some examples finishing rather with exit() or abort(). Abort crashes the app as expected, however the Crash Report produced by Apple then focuses on the handler instead of the code triggering the signal...
Any help appreciated, thanks
Post not yet marked as solved
Hello,
I have received 3 almost identical crash reports from the App Store. They all come from the same user, and they are spaced just ± 45 seconds apart.
This is the backtrace of the crashed thread:
Crashed Thread: 3
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process: Ssssssss [46033]
Thread 3 Crashed:
0 libsystem_kernel.dylib 0x00007ff81b90f196 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007ff81b946ee6 pthread_kill + 263 (pthread.c:1670)
2 libsystem_c.dylib 0x00007ff81b86dbdf __abort + 139 (abort.c:155)
3 libsystem_c.dylib 0x00007ff81b86db54 abort + 138 (abort.c:126)
4 libc++abi.dylib 0x00007ff81b901282 abort_message + 241
5 libc++abi.dylib 0x00007ff81b8f33fb demangling_terminate_handler() + 267
6 libobjc.A.dylib 0x00007ff81b5c67ca _objc_terminate() + 96 (objc-exception.mm:498)
7 libc++abi.dylib 0x00007ff81b9006db std::__terminate(void (*)()) + 6
8 libc++abi.dylib 0x00007ff81b900696 std::terminate() + 54
9 libdispatch.dylib 0x00007ff81b7a6047 _dispatch_client_callout + 28 (object.m:563)
10 libdispatch.dylib 0x00007ff81b7a87c4 _dispatch_queue_override_invoke + 800 (queue.c:4882)
11 libdispatch.dylib 0x00007ff81b7b5fa2 _dispatch_root_queue_drain + 343 (queue.c:7051)
12 libdispatch.dylib 0x00007ff81b7b6768 _dispatch_worker_thread2 + 170 (queue.c:7119)
13 libsystem_pthread.dylib 0x00007ff81b943c0f _pthread_wqthread + 257 (pthread.c:2631)
14 libsystem_pthread.dylib 0x00007ff81b942bbf start_wqthread + 15 (:-1)
In the backtrace of the main thread, I can see that the error is caught by the app delegate which tries to display an alert, but obviously the message has no time to appear. Incidentally (but it's not my main question), I would like to know if it would be possible in such a case to block the background thread for the time the alert is displayed (e.g. using a dispatch queue)?
... (many other related lines)
72 SSUuuuIIIIIIIIIUUuuuu 0x000000010e8089f2 +[NSAlert(Ssssssss) fatalError:] + 32
73 Ssssssss 0x000000010dd5e75b __universalExceptionHandler_block_invoke (in Ssssssss) (SQAppDelegate.m:421) + 333659
74 libdispatch.dylib 0x00007ff81b7a4d91 _dispatch_call_block_and_release + 12 (init.c:1518)
75 libdispatch.dylib 0x00007ff81b7a6033 _dispatch_client_callout + 8 (object.m:560)
76 libdispatch.dylib 0x00007ff81b7b2fcf _dispatch_main_queue_drain + 954 (queue.c:7794)
77 libdispatch.dylib 0x00007ff81b7b2c07 _dispatch_main_queue_callback_4CF + 31 (queue.c:7954)
78 CoreFoundation 0x00007ff81ba62195 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 (CFRunLoop.c:1780)
79 CoreFoundation 0x00007ff81ba21ebf __CFRunLoopRun + 2452 (CFRunLoop.c:3147)
80 CoreFoundation 0x00007ff81ba20ec1 CFRunLoopRunSpecific + 560 (CFRunLoop.c:3418)
81 HIToolbox 0x00007ff8254a5f3d RunCurrentEventLoopInMode + 292 (EventLoop.c:455)
82 HIToolbox 0x00007ff8254a5d4e ReceiveNextEventCommon + 657 (EventBlocking.c:384)
83 HIToolbox 0x00007ff8254a5aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (EventBlocking.c:171)
84 AppKit 0x00007ff81eabfb18 _DPSNextEvent + 858 (CGDPSReplacement.m:818)
85 AppKit 0x00007ff81eabe9c2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 (appEventRouting.m:407)
86 AppKit 0x00007ff81eab1037 -[NSApplication run] + 586 (NSApplication.m:3432)
87 AppKit 0x00007ff81ea85251 NSApplicationMain + 817 (NSApplication.m:9427)
88 dyld 0x00007ff81b5ec41f start + 1903 (dyldMain.cpp:1165)
In all 3 reports, another thread indicates that it is sending or receiving a MIDI data (it's exactly the same backtrace in the 3 reports):
Thread 1:
0 libsystem_kernel.dylib 0x00007ff81b908552 mach_msg2_trap + 10
1 libsystem_kernel.dylib 0x00007ff81b9166cd mach_msg2_internal + 78 (mach_msg.c:201)
2 libsystem_kernel.dylib 0x00007ff81b90f584 mach_msg_overwrite + 692 (mach_msg.c:0)
3 libsystem_kernel.dylib 0x00007ff81b90883a mach_msg + 19 (mach_msg.c:323)
4 CoreMIDI 0x00007ff834adfd50 XServerMachPort::ReceiveMessage(int&, void*, int&) + 94 (XMachPort.cpp:62)
5 CoreMIDI 0x00007ff834b118c5 MIDIProcess::MIDIInPortThread::Run() + 105 (MIDIClientLib.cpp:204)
6 CoreMIDI 0x00007ff834af9c44 CADeprecated::XThread::RunHelper(void*) + 10 (XThread.cpp:21)
7 CoreMIDI 0x00007ff834afae9f CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 77 (CAPThread.cpp:324)
8 libsystem_pthread.dylib 0x00007ff81b9471d3 _pthread_start + 125 (pthread.c:893)
9 libsystem_pthread.dylib 0x00007ff81b942bd3 thread_start + 15 (:-1)
I wonder if this MIDI activity may be related to the crash, even if it doesn't occur in the crashed thread.
I also wonder if the dispatch block starting the backtrace of the thread 3 is the same that leads to the thread 1 (to open the NSAlert), which would mean that it's after the error, or if it's a dispatch block into which the error occurs.
Finally,
2024-03-25_13-04-40.6314.crash
I wonder if std::terminate() could indicate a problem in C++ codes because I have some part of the application written in C++, and it would be a clue.
More generally, is it something in these backtraces that can help me to find what's the problem ?
Any help greatly appreciated, thanks!
-dp
Post not yet marked as solved
Hi,
Updating a macOS application from Ventura to Sonoma, I encountered some issues, especially related to the new default value of -clipsToBounds (NO instead of YES previously), so that I had to add explicit definitions of this method in all my class views.
All these problems are fixed now, except for one that I can't solve and that may or may not be related:
The main window of this application has a toolbar containing a few custom views and using the NSWindowToolbarStyleExpanded style. In Sonoma, I can no longer move the window by clicking and dragging, even when I click on the title bar, and despite the fact that all my custom views inside this toolbar now have their -clipsToBounds method returning YES.
-isMovable however returns YES, -isMovableyWindowBackground returns NO, and the window receives the events. But -mouseDown: is only called when the window can't be moved, which seems to mean that the event wasn't properly caught somewhere.
Curiously, If I put the style to NSWindowToolbarStyleAutomatic, I can move the window again, but only by clicking on the left part (where is displayed the title and the following empty space).
Does anybody encountered such an issue on Sonoma ? Or have an idea to fix or work around this issue ?
Any help or advice is welcome, thank you!
I'm developing a sandboxed application with Xcode which allows the user to open and work with Audio Unit plugins. Working with a beta-tester having a lot of AUs on its laptop running on macOS 12.5.1, we encountered some weird crashes while opening some plugins (Krotos, Flux Audio, Sound Toys, etc.). The message we got was in French, I try to translate it but the original English version could be a little bit different:
Impossible to open “NSCreateObjectFileImageFromMemory-p47UEwps” because the developper can not be verified.
After this first warning, a Fatal Error 100001 message opens and the plugin seems crashed (but not the host).
I easily found some music application users encountering similar issues on the web. From what I read, this error is related to new security rules introduced in macOS 12. And, effectively, some of these plugins tested on an older system work normally. I also read that some (insecure) entitlements of the Hardened Runtime should be able to fix this issue, especially Allow Unsigned Executable Memory Entitlement, whose the doc says:
In rare cases, an app might need to override or patch C code, use the long-deprecated NSCreateObjectFileImageFromMemory (which is fundamentally insecure), or use the DVDPlayback framework. Add the Allow Unsigned Executable Memory Entitlement to enable these use cases. Otherwise, the app might crash or behave in unexpected ways.
Unfortunately, checking this option didn't fix the issue. So, what I tried next was to add Disable Executable Memory Protection (no more success), and finally Allow DYLD Environment Variables and Allow Execution of JIT-compiled Code: none of them solved my problem.
I really don't see what else to do, while I'm sure that a solution exists because the same plugins work perfectly on other application (Logic, Live Ableton). Any help would be greatly appreciated. Thanks !
-dp.