Printable View
this may have been asked before, but I couldn't find it in a search, and no useful results on google. is there any way at all to figure out what thread in a multithreaded program generates a fault? I can get the fault address by using sigaction(), but it would be nice to get the current thread id and just kill that thread instead of shutting down the whole application.
A signal due to a hardware exception (such as a fault) is always delivered to the thread which caused it. So the SIGSEGV handler is executing in the context of the faulting thread. Make sure you're not blocking SIGSEGV with the per-thread signal mask, though.Quote:
Originally Posted by Elkvis
One problem is that you can't call any pthread function from within a signal handler. That includes pthread_self(). So you have to find some other way to communicate back to the main execution path that the thread has generated a fault.
It's generally a lot easier to let the whole program die when a thread takes a fault.
can't? is this just an example of undefined behavior, or is there some mechanism that simply blocks these calls from working under those conditions?Quote:
Originally Posted by brewbuck
do you have any suggestions on how I might accomplish this? with many threads running at once, and being unable to call pthread_self() after a fault has occurred, it seems like it could be very difficult to know which thread is emitting the signal. Is there any way to define callbacks that can set a global variable every time a thread context switch happens?Quote:
So you have to find some other way to communicate back to the main execution path that the thread has generated a fault.
easier, yes. but in my case, where the program is a TCP server that handles many clients at once, many of which may be performing financial transactions, it's not a good idea to simply terminate the program and attempt a restart. I know it's safe to use the fork and exec* functions from inside a handler, but this seems like a rather extreme way to handle a single thread crashing.Quote:
It's generally a lot easier to let the whole program die when a thread takes a fault.
Edit:
My server is currently a multi-process application that forks and hands off the incoming connections to the child, but I'd like to switch to a multithreaded approach for better communication between the client connections.
I think it's undefined behavior. I was Googling after I read your post, and discovered at least a few people who claimed that pthread_self() was broken inside a signal handler (returning the wrong ID) on certain platforms but not others.Quote:
Originally Posted by Elkvis
Not being able to call pthreads functions in the signal handler is a HUGE limitation. I'm not really sure how you can do this, portably. On many platforms, each thread has a unique PID and so you might be able to use getpid(), combined with some kind of data structure which maps PIDs to thread IDs. The problem is that you can't actually kill the thread from within the signal handler (since you can't use pthread_kill). So the signal handler has to return and allow the thread to continue. So you'd need some kind of check after every possible instruction which could generate a fault to see whether you've taken a signal.Quote:
do you have any suggestions on how I might accomplish this?
It seems to suck pretty bad, honestly.
I've done some testing and discovered that pthread_self() returns the id of the faulting thread on the Linux 2.6.22 kernel that runs on my OpenSuse server, so I suspect that Linux is one of the platforms on which it is not broken. Unfortunately, I cannot call pthread_cancel() or pthread_exit() from within the signal handler without catastrophic results (in the context of the process). calling pthread_exit() terminates the process, and pthread_cancel() throws another signal.Quote:
Originally Posted by brewbuck