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.