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
Previous text:
2003-10-02 17:52: 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.
Can Pike backtraces be dumped on SIGSEGV?
Yes, why not?
How will the security mechanism around that look like?
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.
Turn of catching SIGSEGV in the SIGSEGV handler?
It's probably good to be able to disable it from inside pike.
o Implement this_function().
Is this tricky?
Not at all.
/ Martin Stjernholm, Roxen IS