Can't you get a coredump? It's usually just as helpful.
Another thing you perhaps can try is to compile Pike with --with-rtldebug. It'll run slower but not unbearably so, and there's a fair chance the extra internal checks will give you a better error to report. (The next step is to add -d but that will probably make it too slow for heavy production use.)
As for catching SIGSEGV in pike, it's possible strictly speaking (just use the normal signal() function), but I suspect it won't work well to try to run any pike code after it has happened. And besides, it's the C-level state that usually is interesting for such errors, and you can't get to that from inside pike. So running gdb on a coredump is much better.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-09-12 00:15: Subject: Catching segfault
Hello list,
I have a segfault with a Pike that happens rarely on a busy Camas server. To get a backtrace and fill a bug report I've tried to run it into gdb however I didn't get any segfault for now and I can't run it into gdb for a long time since it is a production server (I saw this error only one time on the development server, too few traffic). Maybe it's not even possible to have a segfault inside gdb because of a strange side effects (maybe the segfault occurs only on a fast process or something).
So I'd like to know if it would be possible to catch SIGSEGV in Pike and output a backtrace so that:
. You might get more bug reports. . It would be possible to track problems when it's not possible to run inside a debugger or that the error don't happen in this case.
Thank you for your reply.
-- David Gourdelier
/ Brevbäraren