Hi all : I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal? Thanks!
Hi! On 21:46 Sat 10 May , net.study.sea@gmail.com wrote:
Hi all : I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
Thanks!
Yes, you can hook SIGSEGV like a normal signal. However, I have never tried to do so... -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com
After you get a SIGSEGV, you are screwed. You can probably recover if you do a lot of work, but overall it's not worth it. Also in a signal handler you are not guaranteed malloc() will work, the kernel may not allow you to allocate more memory. Also your signal handler for SIGSEGV will keep getting called because the SIGSEGV keeps coming until the program exits. Note that you are not recommended to use functions such as printf() in a signal handler (see: https://www.securecoding.cert.org/confluence/display/seccode/SIG30-C.+Call+o...). It might be worth looking into things like libsigsegv: http://libsigsegv.sourceforge.net/ I hope this can help!
Hi, Le mardi 13 mai 2014 à 17:29 +0200, michi1@michaelblizek.twilightparadox.com a écrit :
On 21:46 Sat 10 May , net.study.sea@gmail.com wrote:
Hi all : I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
Thanks!
Yes, you can hook SIGSEGV like a normal signal. However, I have never tried to do so...
I've played with this: in the segv signal handler, using SA_SIGINFO (see sigaction(3), I've retrieved the fault address and mmap() some anonymous memory page here, then leave the handler. At this point the kernel will resume the process/thread where it has triggered the fault. And voila. The process/thread will issue again the previously faulty instruction and succeed. This approach works when fault happen on a unmapped address. But if your process/thread is trying to read some values there and instead found a page full of 0, it might trigger more segfault. Especially if it's using the zero as a pointer: it's going to try to access to page 0, which, by default, is not map'able by userspace process to defeat kernel NULL pointer dereference vulns. For write access to a read only page, depending on the underlying mapping, you will not be able to recover from the error easily: You probably have to unmap the read-only page, map an anonymous page instead, and don't forget to restore the content the process was expected to find there. I've never tried the later, nor played with multiple threads triggering fault. So YMMV. Regards. -- Yann Droneaud OPTEYA
On 2014-05-10 21:46:01 (+0800), net.study.sea@gmail.com <net.study.sea@gmail.com> wrote:
I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
Yes, as others have already pointed out, you can hook SIGSEGV like any other signal. You're not going to be able to save the process any more, but you can still collect some useful information. I've found it very useful to have a SIGSEGV (and SIGPIPE, SIGABRT, SIGFPE, SIGILL) handler which logs a backtrace (look at 'man backtrace') to syslog. Very useful for debugging on targets where core dumps are impractical. Others have also pointed out that it might no longer be safe to call printf() or malloc() there. That's true, but usually it's OK, and if it turns out that it wasn't ... Well, you were crashing anyway. Regards, Kristof
On Wed, May 14, 2014 at 4:14 PM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2014-05-10 21:46:01 (+0800), net.study.sea@gmail.com <net.study.sea@gmail.com> wrote:
I want to know is it possible to hook SIGSEGV to restart the thread which the signal is sent to,without restart the whole process? And record the place where has caused this signal?
Yes, as others have already pointed out, you can hook SIGSEGV like any other signal.
You're not going to be able to save the process any more, but you can still collect some useful information.
I've found it very useful to have a SIGSEGV (and SIGPIPE, SIGABRT, SIGFPE, SIGILL) handler which logs a backtrace (look at 'man backtrace') to syslog. Very useful for debugging on targets where core dumps are impractical.
Others have also pointed out that it might no longer be safe to call printf() or malloc() there. That's true, but usually it's OK, and if it turns out that it wasn't ... Well, you were crashing anyway.
Well, not anyway: you still should be able to take a longjmp out of the signal handler to a safe place. -- Thanks. -- Max
participants (6)
-
Kristof Provost -
Max Filippov -
michi1＠michaelblizek.twilightparadox.com -
net.study.sea＠gmail.com -
Sam Dodrill -
Yann Droneaud