Hi!
I'm having an issue running codeclap on 10.15 Catalina. The app starts fine, but when i hit "start this configuration" immediately crashes. I have a crash report but it seems i can't attach it to this post. Here's a small snippet:
I can send you the report by email, though not sure which.
I'm having an issue running codeclap on 10.15 Catalina. The app starts fine, but when i hit "start this configuration" immediately crashes. I have a crash report but it seems i can't attach it to this post. Here's a small snippet:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 | Crashed Thread: 6 Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000202707ed7 Exception Note: EXC_CORPSE_NOTIFY External Modification Warnings: Process used task_for_pid(). VM Regions Near 0x202707ed7: VM_ALLOCATE 00000001b5dfd000-00000001b9cfd000 [ 63.0M] ---/rwx SM=NUL --> MALLOC_NANO 0000600000000000-0000600008000000 [128.0M] rw-/rwx SM=PRV Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff67609146 mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff676096ac mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff301c219b __CFRunLoopServiceMachPort + 322 3 com.apple.CoreFoundation 0x00007fff301c1737 __CFRunLoopRun + 1695 4 com.apple.CoreFoundation 0x00007fff301c0e13 CFRunLoopRunSpecific + 499 5 com.apple.HIToolbox 0x00007fff2ed4db2d RunCurrentEventLoopInMode + 292 6 com.apple.HIToolbox 0x00007fff2ed4d86d ReceiveNextEventCommon + 600 7 com.apple.HIToolbox 0x00007fff2ed4d5f7 _BlockUntilNextEventMatchingListInModeWithFilter + 64 8 com.apple.AppKit 0x00007fff2d3e3ac4 _DPSNextEvent + 990 9 com.apple.AppKit 0x00007fff2d3e2834 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 10 com.apple.AppKit 0x00007fff2d3dcfd4 -[NSApplication run] + 658 11 codeclap.osx 0x000000010d87e9d5 main + 533 12 libdyld.dylib 0x00007fff674c0405 start + 1 Thread 6 Crashed: 0 libsystem_kernel.dylib 0x00007fff6760f47a __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff676cc707 pthread_kill + 384 2 libsystem_c.dylib 0x00007fff67597a08 abort + 120 3 codeclap.osx 0x000000010daf67da CheckpointSignalHandler.cold + 5 4 ??? 0x00007fffd9806710 0 + 140736842458896 |
I can send you the report by email, though not sure which.
Edited by Aleksandr Ivanov
on
Reason: Initial post
Hi,
for any kind of additional information or questions you can write to [email protected].
I'm afraid though that in this particular case a dump may be of reduced value. The crash you see is a "self-induced" abort when codeclap encounters a situation the program knows no way of recovering from. Unfortunately this is implemented in a way that I don't think there is a way of deducing the original problem post-mortem. I will look into changing this mechanism for the next update so that the root cause of the fault is not lost in transit.
Also I checked to see if I find an easy way of reproducing this problem, for this I had to setup a clean system as the OS (or gatekeeper to be precise) may act differently depending if an application is known, was downloaded, etc. However I wasn't able to yet. I assume you have checked with a minimal test program compiled with something like "clang -g -O0 test.c"? Does the debugger reach the point where the OS asks for the password in order for the debugger to "take control of another process" (this only shows up once after every restart), does is occur directly after that point?
If you are eager to check for additional information before the next update you could start codeclap with lldb instead of starting the .app directly (simply open a terminal and start the codeclap.osx binary from the .app bundle in the Contents/MacOS folder). When run this way lldb will stop at the correct position when the initial problem occurs.
At this point it may already be enough to have a thread list ("tr list" from lldb) and a trace from the thread that crashes ("thr sel x", x can be seen in the initial lldb message when lldb stops, and "bt" after that).
The only explanation that comes to my mind is that it could be something thrown by Core Services, Apple Frameworks can react pretty harsh (as in just throw an exception and watch the world burn) when they encounter something they don't like.
for any kind of additional information or questions you can write to [email protected].
I'm afraid though that in this particular case a dump may be of reduced value. The crash you see is a "self-induced" abort when codeclap encounters a situation the program knows no way of recovering from. Unfortunately this is implemented in a way that I don't think there is a way of deducing the original problem post-mortem. I will look into changing this mechanism for the next update so that the root cause of the fault is not lost in transit.
Also I checked to see if I find an easy way of reproducing this problem, for this I had to setup a clean system as the OS (or gatekeeper to be precise) may act differently depending if an application is known, was downloaded, etc. However I wasn't able to yet. I assume you have checked with a minimal test program compiled with something like "clang -g -O0 test.c"? Does the debugger reach the point where the OS asks for the password in order for the debugger to "take control of another process" (this only shows up once after every restart), does is occur directly after that point?
If you are eager to check for additional information before the next update you could start codeclap with lldb instead of starting the .app directly (simply open a terminal and start the codeclap.osx binary from the .app bundle in the Contents/MacOS folder). When run this way lldb will stop at the correct position when the initial problem occurs.
At this point it may already be enough to have a thread list ("tr list" from lldb) and a trace from the thread that crashes ("thr sel x", x can be seen in the initial lldb message when lldb stops, and "bt" after that).
The only explanation that comes to my mind is that it could be something thrown by Core Services, Apple Frameworks can react pretty harsh (as in just throw an exception and watch the world burn) when they encounter something they don't like.
Edited by spx
on