Injecting a C++ exception in another thread

Question

With the C++0x feature of exception_ptr one can store an exception in one thread and have another thread access it. However, the other thread has to call rethrow_exception(). In some cases, however, I need to actually interrupt the other thread and have the exception be raised there immediately; polling the exception_ptr for non-null is not a solution.

I found a solution for how to inject an exception in Windows at http://www.codeproject.com/KB/exception/ExcInject.aspx by suspending a thread and modifying its instruction pointer register before resuming it. However, I also need my code to run on Linux. How do I accomplish it there?

If I use something like getcontext(), that gets the current thread's context (whereas in Windows, GetContext() accepts a thread parameter), so I would have to call it in a signal handler. But I've read that getcontext()/setcontext() should not be called in signal handlers... Alternatively, I could call rethrow_exception() directly in the signal handler, but I'm worried this won't have the intended effect, where the interrupted thread has the stack unwound in the same way with all destructors of the scope the interruption was in called etc.

score 4 · Answer 1 · edited May 23 '17 at 12:33

I asked more or less the same question here. After some time I found a good answer. Here is the code, you can find more comments in my answer:

#include <thread>
#include <signal.h>
#include <unistd.h>
#include <iostream>

using namespace std;

//Custom exception which is used to stop the thread
class StopException {};

void sig_fun(int s)
{
    if(s == SIGUSR2)throw StopException();
}

void threadFunction()
{
    cout<<"Thread started"<<endl;
    try {
        while(true)
        {
            //Work forever...
            sleep(1);
        }
    } catch(const StopException &e) {
        cout<<"Thread interrupted"<<endl;
    }
    cout<<"Thread stopped"<<endl;
}

int main(int argc, char *args[])
{
    //Install Signal handler function
    signal(SIGUSR2, sig_fun);
    pthread_t threadObject;
    thread t([&threadObject]()
    {
        //Store pthread_t object to be able to use it later
        threadObject = pthread_self();
        threadFunction();
    });

    string temp;
    cout<<"Write something when you want the thread to be killed"<<endl;
    cin>>temp;

    //Send Signal to thread
    pthread_kill(threadObject, SIGUSR2);
    t.join();
}

Will the signal interrupt immediately regardless of what the target thread is doing? That is, if instead of it being blocked in a kernel wait in the sleep() call, what if the thread is in an infinite loop in user space? Also, do you know any way to modify the instruction pointer of a pthread? — Display Name, Mar 09 '16 at 18:11

score 2 · Accepted Answer · answered Dec 10 '10 at 22:16

2

I read that article you linked to some time ago, and I was a bit skeptical.

The approach of modifying another thread's instruction pointer directly feels VERY scary. You have absolutely no idea what operation you're interrupting and leaving half-completed, and the interrupted operation may not be expecting an exception and thus have no ability to clean up after itself.

On Windows, I've used QueueUserAPC successfully to abort other threads once they enter an alertable wait state. I don't know of any direct equivalent for this in Linux.

answered Dec 10 '10 at 22:16

Roddy

66,617
42
165
277

Feel free to be a bit less skeptical. This is Russian roulette, "how do I randomly deadlock my program". It is a debugger API function. – Hans Passant Dec 10 '10 at 23:18
Why would it lead to deadlock? – Display Name Dec 11 '10 at 00:31
1

@Borislav: you potentially prevent the execution (cleanup) of lock, thus causing deadlock. Herb Sutter had an article on this on Dr Dobbs: you should never interrupt a thread, you should always ask it politely if it could interrupt itself. – Matthieu M. Dec 11 '10 at 11:33
1

It seems to me that using scoped locks avoids this issue. When interrupted thread resumes, it immediately rethrows the exception, which would cause scoped lock destructors to execute. So what's the problem? A locking process itself cannot be interrupted because system calls do not get interrupted (calling say SuspendThread() will only actually suspend the thread when a system call in progress completes). – Display Name Dec 13 '10 at 06:56
@Borislav: Scoped locks (and RAII in general) fixes only part of the problem. By 'hacking' the instruction pointer to invoke an exception, it means an exception could theoretically be thrown by every single machine instruction, including NOPs, so the state of the interrupted code can be in an invalid intermediate state. Besides, re scoped locks: Your code may use scoped locks, but what about any 3rd party libraries you use? – Roddy Dec 13 '10 at 15:06

Injecting a C++ exception in another thread

2 Answers2