I think I meant, what happens if the backtrace SIGSEGVs:
Well, it shouldn't do describe_backtrace(backtrace()). Rather it'd use gdb_backtraces() (see interpret.c) which is less fancy but much more robust. Still, it can segfault by following an invalid pointer so some care must be taken to handle that situation at least somewhat gracefully.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-02 17:55: Subject: Some tasks from the conference
I would like an option to pike that dumps a pike backtrace on SIGINT as well. (Or as default behaviour.)
An option or environment setting to enable it for any signal would be nice, but I definitely don't think it should be the default for SIGINT.
Possibly not. Using SIGQUIT might be useful, though.
Can Pike backtraces be dumped on SIGSEGV?
Yes, why not?
Because the memory might be faulty. 99% of all my SIGSEGVs seems to be because the memory allocation info is broken, and thus all consequent calls to malloc or free SIGSEGVs...
You mean wrt the pike security system, or security in general, e.g. concerns about a user segfaulting a process to get access to sensitive data on the stack? I think the last part should be solved by self-sensoring string objects, which were discussed a while back.
I think I meant, what happens if the backtrace SIGSEGVs:
Turn of catching SIGSEGV in the SIGSEGV handler?
But an eye on the security features would be nice too. A sensitive-string-object should be implemented.
/ Mirar