Crashes on macOs Catalina

4lex1v

Aleksandr Ivanov

1 posts

This newly registered member has not yet activated their account.

#21867

Crashes on macOs Catalina

4 years, 5 months ago Edited by Aleksandr Ivanov on November 17, 2019, 4:21pm Reason: Initial post

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:

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.

spx

148 posts / 1 project

#21873

Crashes on macOs Catalina

4 years, 5 months ago Edited by spx on November 19, 2019, 10:58am

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.

spx

148 posts / 1 project

#21875

Crashes on macOs Catalina

4 years, 5 months ago

I am curious if you can see something different/changed with 0.9.1. If it still crashes for you, the generated report should provide better information.
If it does not crash anymore you can execute it on the terminal so see output for possibly thrown exceptions.