get id of faulting thread

This is a discussion on get id of faulting thread within the Linux Programming forums, part of the Platform Specific Boards category; this may have been asked before, but I couldn't find it in a search, and no useful results on google. ...

  1. #1
    Registered User
    Join Date
    Oct 2006
    Posts
    2,415

    get id of faulting thread

    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.

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elkvis View Post
    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.

    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Oct 2006
    Posts
    2,415
    Quote Originally Posted by brewbuck View Post
    One problem is that you can't call any pthread function from within a signal handler. That includes pthread_self().
    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?

    So you have to find some other way to communicate back to the main execution path that the thread has generated a fault.
    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?

    It's generally a lot easier to let the whole program die when a thread takes 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.

    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.
    Last edited by Elkvis; 04-27-2009 at 03:17 PM.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by Elkvis View Post
    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?
    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.

    do you have any suggestions on how I might accomplish this?
    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.

    It seems to suck pretty bad, honestly.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Registered User
    Join Date
    Oct 2006
    Posts
    2,415
    Quote Originally Posted by brewbuck View Post
    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.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Thread Synchronization in Win32
    By passionate_guy in forum C Programming
    Replies: 0
    Last Post: 02-06-2006, 04:34 AM
  2. [code] Win32 Thread Object
    By Codeplug in forum Windows Programming
    Replies: 0
    Last Post: 06-03-2005, 03:55 PM
  3. Win32 Thread Object Model Revisted
    By Codeplug in forum Windows Programming
    Replies: 5
    Last Post: 12-15-2004, 07:50 AM
  4. Simple thread object model (my first post)
    By Codeplug in forum Windows Programming
    Replies: 4
    Last Post: 12-12-2004, 10:34 PM
  5. Problem : Threads WILL NOT DIE!!
    By hanhao in forum C++ Programming
    Replies: 2
    Last Post: 04-16-2004, 01:37 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21