How to make Mac OS X CrashReporter invoke debugger?

I have an Apache module on Mac OS X that produces random crashes. I can reproduce these crashes with certain sequence of actions, and these crashes produce Crash Reporter dialog "httpd quit unexpectedly". Is there a way to cause Crash Reporter launch debugger (xcode, gdb, anything) instead of just displaying the backtrace?

I've tried running httpd under gdb with httpd -X but the crash do开发者_运维问答esn't happen then - it happens only if many httpd's are running at once, and I found no way to attach gdb to all of them at once. So I was hoping maybe I can cause CrashReporter to attach the debugger when specific process crashes - is there a way to do it?

Unfortunately, the type of bug you describe has a tendency to disappear when perturbed by examination.

That said, an option to try is launching a GDB session from inside your module. QA1573 has an example using DTrace, which would seem a bit cleaner, but after some experimentation this doesn't seem to work terribly well with multiple processes. (I could not see a way to get DTrace to attach gdb at the time the process crashes; you only get a proc::postsig:signal-handle probe triggered after the process has already crashed.)

You could do something like this from your module:

% echo 'c' > continue.txt
% osascript -e 'tell app "Terminal" to do script "gdb -x continue.txt attach <pid>"'

which would open a separate Terminal window for each httpd process.

You could also start gdb from outside instead, with a script (DTrace or otherwise) watching for httpd processes, and use the SIGSTOP method from QA1573 in your module's code to wait until the script noticed the new httpd.

After few months, I guess we can say the answer is no, you can't. :)

To debug your problem, the crash report should be exploitable... but if really not, you might try to enable apache error log and also your own logging code. Then watching logs / console when a crash occurs should help.

This isn't, to the best of my knowledge or google-fu, possible, nor would it entirely make sense. It is not possible to do this from CrashReporter regardless, as your program has already aborted by the time it runs.

However, it is possible to use GDB after the fact by getting httpd to generate core dumps whenever a process kicks the bucket. Apache's own documentation on debugging crashes outlines the best practices for setting it up.

If you haven't already, don't forget to rebuild apache with -g so you have debugging stubs, or you'll end up with garbled symbol names.

This is old, but just came up first on a search, so:

No, you can't do this from within the CrashReporter. You can however avoid that the CrashReporter is called by installing your own signal handler. KDE does this for instance to install its own crash handler. My understanding is that in case of an exception that would lead to a crash, the handler invokes an application that will handle the crash (DrKonqi) with the relevant information, and then suspends itself (sends itself a SIGSTOP after receiving, say, a SIGSEGV). DrKonqi will then provide the user with several options, including to get a backtrace, which is done via gdb or lldb on OS X.

There's nothing to prevent you from using a similar approach to launch a standalone (GUI) debugger and let it attach to the failing process. This would be almost the same as attaching to the process before the exception, except of course for any register, stack etc. corruption the exception may have caused.