Thread, ansi c signals and Qt

inopportuno

I'm writing a multithread plugin based application. I will not be the plugins author. So I would wish to avoid that the main application crashes cause of a segmentation fault in a plugin. Is it possible? Or the crash in the plugin definitely compromise also the main application status? I wrote a sketch program using qt cause my "real" application is strongly based on qt library. Like you can see I forced the thread to crash calling the trimmed function on a not-allocated QString. The signal handler is correctly called but after the thread is forced to quit also the main application crashes. Did I do something wrong? or like I said before what I'm trying to do is not achievable? Please note that in this simplified version of the program I avoided to use plugins but only thread. Introducing plugins will add a new critical level, I suppose. I want to go on step by step. And, overall, I want to understand if my target is feasible. Thanks a lot for any kind of help or suggestions everyone will try to give me.

@#include <QString>
#include <QThread>
#include<csignal>
#include <QtGlobal>
#include <QtCore/QCoreApplication>

class MyThread : public QThread
{
public:
static void sigHand(int sig)
{
qDebug("Thread crashed");
QThread* th = QThread::currentThread();
th->exit(1);
}

MyThread(QObject * parent = 0)
:QThread(parent)
{
    signal(SIGSEGV,sigHand);
}

~MyThread()
{
    signal(SIGSEGV,SIG_DFL);
    qDebug("Deleted thread, restored default signal handler");
}

void run()
{
    QString* s;
    s->trimmed();
    qDebug("Should not reach this point");
}

};

int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
MyThread th(&a);
th.run();
while (th.isRunning());
qDebug("Thread died but main application still on");
return a.exec();
}@

lgeyer

Be aware that your application is either in an undefined state or resumes execution where it has left when the signal handler returns, which is, in your case a still faulty instruction in a now deleted thread.

In addition, you should only use async-signal-safe functions from within a signal handler (and even then there are restrictions, especially when it comes to portability).

In either case you haven't won anything, as there is no guarantee that a plugin only messes up its own memory or thread, it might mess up yours as well as they share the same address space.

If you want to prevent such situations you will have to enforce seperate address spaces, which means your plugins will have to run in a seperate process.

AcerExtensa

bq. If you want to prevent such situations you will have to enforce seperate address spaces, which means your plugins will have to run in a seperate process.

Absolutely true, you will be on secure side only with sandboxed plugins.

inopportuno

With "sandboxed plugin" did you mean processes?

AcerExtensa

Yes, with sandbox I mean space where the child(process) has its own separate allocated address space(sandbox) and can do what ever he want without touching address space(sand) of parent process. You can declare some kind of communication mechanism for future plugins/for plugin developers and communicate with plugins over RPC, pipes etc... You also should have plan about which kind of data manipulation are available from plugin side. Best practice to communicate with plugins with static data like(server/client communication), but if you need to provide some kind of pointer to dynamic data(class instance, interface), don't share the pointer of the whole instance. For example if plugin should draw something on widget and do it very fast so it can't be made over RPC, share only the pointer to the drawable surface and not to the whole QWidget or whatever...

inopportuno

Thanks a lot for the clarification.