QApplication recover from segmentation fault - qt

I want to be able to recover from a Segmentation Fault in MyApplication by catching the SIGSEGV and restarting QApplication. So for testing purposes I'm injecting a segmentation fault in my code.
The issue is that the signal handler that catches the SIGSEGV is getting a non-stop stream of SIGSEGVs. At first I thought it was the while loop in my main but it still happens even though I comment out the while loop. So my questions are simple: Is it even possible to recover from a Segmentation Fault in Qt? Why am I getting rolling SIGSEGVs non-stop?
#include <QApplication>
#include <QDebug>
#include "MyApplication.h"
#include <initializer_list>
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
#define RESTART_CODE 1000
void catchUnixSignals(std::initializer_list<int> quitSignals)
{
auto handler = [](int sig) -> void
{
if (sig == SIGSEGV)
{
QCoreApplication::exit(RESTART_CODE);
}
else
{
QCoreApplication::quit();
}
};
sigset_t blocking_mask;
sigemptyset(&blocking_mask);
for (auto sig : quitSignals)
sigaddset(&blocking_mask, sig);
struct sigaction sa;
sa.sa_handler = handler;
sa.sa_mask = blocking_mask;
sa.sa_flags = 0;
for (auto sig : quitSignals)
sigaction(sig, &sa, nullptr);
}
int main(int argc, char *argv[])
{
catchUnixSignals({SIGSEGV, SIGQUIT, SIGINT, SIGTERM, SIGHUP, SIGKILL});
int i = 0;
do
{
QApplication app(argc, argv);
MyApp myapp;
MyApp.start();
app.exec();
if (app.exec() != RESTART_CODE) break;
} while(1);
return 0;
}

This does not directly answers your question, but is another way to achieve similar behavior.
To recover from a segmentation fault, an option is to use a watchdog, i.e. another independent process that checks the status of your main software and restarts it when needed.
When you start your software, you create another process that runs a 2nd software, the watchdog. Ensure to start it in "detached" mode to avoid that it gets closed if your main software crashes.
In the watchdog, frequently call "tasklist" on Windows or "ps" or "top" on Linux and parse the output to check whether your software is still running. OR, use a UDP or TCP port to communicate between the main software and the watchdog, to tell the watchdog that the main software is still running well.
In the watchdog, if the main software is no longer running, restart the main software process (also in detached).
CAUTION: You need to manage the case where the main software is exited correctly. In that case the main software should either kill the watchdog itself when exiting normally (calling "kill" on the pid), or send it a message so that the watchdog exits as well.

Related

Unable to send and receive images between 2 Raspberry connected to Zigbee via UART

I have 2 Raspberry Pi4 connected to Zigbee via UART, I wrote the program to receive and send between the two devices. My program can send and receive character data very accurately, but when I send data from a photo, the program never receives enough data. I tried a PC connected to Zigbee and sent pictures to Pi via RealTerm, on Pi I received photos. What is the problem here? Or does anyone have another way to send photos between 2 Raspberry connected to Zigbee via UART? Thanks very much.
Program send:
#include "ui_serial.h"
#include <QDebug>
#include <QBuffer>
#include <QPixmap>
#include <QFile>
serial::serial(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::serial)
{
ui->setupUi(this);
serialPort = new QSerialPort(this);
serialPort->setPortName("ttyAMA0");
serialPort->setBaudRate(QSerialPort::Baud115200);
serialPort->setDataBits(QSerialPort::Data8);
serialPort->setStopBits(QSerialPort::OneStop);
serialPort->setFlowControl(QSerialPort::NoFlowControl);
serialPort->open(QIODevice::ReadWrite);
if (serialPort->isOpen() == true){
qDebug() <<"Port Opened....";
connect(serialPort, SIGNAL(readyRead()), this, SLOT(on_readdata()));
}
}
void serial::on_pushButton_2_clicked()
{
QFile* imageFile = new QFile("/home/pi/Desktop/image.jpg");
imageFile->open(QIODevice::ReadOnly);
QByteArray ba = imageFile->readAll();
imageFile->close();
delete imageFile;
if(serialPort->isOpen()==true){
serialPort->write(ba);
qDebug()<<ba.size()<<"size_send:";
}
}
Program read:
#include "ui_serial.h"
#include <QDebug>
#include <QBuffer>
#include <QPixmap>
#include <QFile>
#include <QMessageBox>
serial::serial(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::serial)
{
ui->setupUi(this);
serialPort = new QSerialPort(this);
serialPort->setPortName("ttyAMA0");
serialPort->setBaudRate(QSerialPort::Baud115200);
serialPort->setDataBits(QSerialPort::Data8);
serialPort->setStopBits(QSerialPort::OneStop);
serialPort->setFlowControl(QSerialPort::NoFlowControl);
serialPort->open(QIODevice::ReadWrite);
if (serialPort->isOpen() == true){
qDebug() <<"Port Opened....";
connect(serialPort, SIGNAL(readyRead()), this, SLOT(on_readdata()));
}
}
void serial::on_readdata()
{
QByteArray ba;
while (serialPort->waitForReadyRead(1000)){
ba.append(serialPort->readAll());
}
qDebug()<<ba.size()<<"sizeeeee:";
QFile newDoc("/home/pi/Desktop/imagexx.jpg");
if(newDoc.open(QIODevice::WriteOnly)){
newDoc.write(ba);
}
newDoc.close();
}
serialPort->setFlowControl(QSerialPort::NoFlowControl);
I see that the sending end isn’t using flow control. You definitely need to do that so you don’t overflow buffers on the XBee module. Without flow control, you’ll end up sending data that won’t get transmitted. My guess is that Real Term had flow control enabled, and that’s why your data arrived.
You should also enable it on the receiver, although it’s less likely you won’t be able to keep up with the data coming in.
I don’t know the details of the API on the receiving end, but it should be prepared for delays on received data. You could wait for a 1-2 second quiet period (while receiving and appending that data to your buffer) before considering the transfer “done” and saving the file.

Qt, QCoreApplication and QFtp

I want to use QFtp for the first time and googled a lot to find out how it should be used. This, among others is a typical example:
#include <QCoreApplication>
#include <QFtp>
#include <QFile>
int main(int argc, char ** argv)
{
QCoreApplication app(argc, argv);
QFile *file = new QFile( "C:\\Devel\\THP\\tmp\\test.txt" );
file->open(QIODevice::ReadWrite);
QFtp *ftp = new QFtp();
ftp->setTransferMode(QFtp::Active);
ftp->connectToHost("ftp.trolltech.com");
ftp->login();
ftp->cd("qt");
ftp->get("INSTALL",file);
ftp->close();
QObject::connect(ftp, SIGNAL(done(bool)), &app, SLOT(quit()));
int ret = app.exec();
delete ftp;
delete file;
return ret;
}
The question:
As far as I understood, the QCoreApplication app is needed to handle the "done" signal, emmited upon finalization of ftp-get. Now, the ftp->get is called before the connect and even before the app handler is running at all (app.exec() is called afterwards).
What happens, if the file transfer has completed already before the "connect" statement? In fact, that will not happen, but I could put an artificial delay of, say 1 minute between ftp->close() and the connect(...). During this time, the ftp get will surely be finished. What would happen?
Note that QFtp is really only meant for legacy Qt applications and it is now suggested that QNetworkAccessManager and QNetworkReply are used instead, as detailed in the Qt documentation.
That being said, with your connect call being positioned after the connection to the FTP site and retrieving of the file, should the file be downloaded first, the 'quit' signal would never be reached. If you make the connection straight after creating the QFtp object, then this won't be an issue: -
QFtp *ftp = new QFtp();
QObject::connect(ftp, SIGNAL(done(bool)), &app, SLOT(quit()));
This guarantees that the 'quit' slot will be called when the QFtp object emits the 'done' signal.
QFtp *ftp = new QFtp();
QObject::connect(ftp, SIGNAL(done(bool)), &app, SLOT(quit()));
ftp->setTransferMode(QFtp::Active);
ftp->connectToHost("ftp.trolltech.com");
ftp->login();
ftp->cd("qt");
ftp->get("INSTALL",file);
ftp->close();
int ret = app.exec();
In reality though, I would expect the connect in your example would complete before the machine had time to negotiate a connection to another server, login and start the download of the file.

freebsd network program compilation

I am trying to compile some simple networking programs on freebsd 8 and running into compilation issues. I am creating a simple client-server programs but no function or structure from networking is not getting compiled.
For eg. I use standard socket() call to create a socket but I run into an error "Called object socket is not a function."
If I remove the network code then my toy program compiles. For simplicity I have just put a simple example which does not compile. :
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
void main(){
int socket = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP);
printf("Could create sockets without any issues.\n");
}
I compiled it with "cc toy_prog.c -lc" and gave me the mentioned error.
A very simple error. You have defined a local variable with the same name as the external function you are trying to call (socket). Try the following and you will get the same error:
int f()
{
return 0;
}
void main()
{
int f = f();
}

How to start video-suite in MeeGo / Nokia N9 from Qt code?

I am having problems with launching Nokia's own video player from my application that I just don't seem to be able to solve.
My first attempt included calling
Qt.openUrlExternally(url)
from QML and that seemed to do the trick just fine, except that it opened the browser every time and used it instead of the video-suite (native player).
Next I tried cuteTube -approach where I start new process like this:
QStringList args;
args << url;
QProcess *player = new QProcess();
connect(player, SIGNAL(finished(int, QProcess::ExitStatus)), player, SLOT(deleteLater()));
player->start("/usr/bin/video-suite", args);
That worked, except that it required video-suite to be closed upon calling player->start, otherwise it did nothing.
My third attempt involved starting the video-suite via QDBus, but that didn't work any better:
QList<QVariant> args;
QStringList urls;
urls << url;
args.append(urls);
QDBusMessage message = QDBusMessage::createMethodCall(
"com.nokia.VideoSuite",
"/",
"com.nokia.maemo.meegotouch.VideoSuiteInterface",
"play");
message.setArguments(args);
message.setAutoStartService(true);
QDBusConnection bus = QDBusConnection::sessionBus();
if (bus.isConnected()) {
bus.send(message);
} else {
qDebug() << "Error, QDBus is not connected";
}
The problem with this is that it requires video-suite to be up and running - autoStartService parameter didn't help either. If video-suite isn't running already, the call opens it just fine but, alas, no video starts to play.
Eventually I tried using also VideoSuiteInterface, but even having the program compile with it seemed to be difficult. When I eventually managed to compile and link all relevant libraries, the results didn't differ from option 3 above.
So, is there a way to use either VideoSuiteInterface directly or via DBus so that it would start video playback regardless of the current state of the application?
The solution was actually simpler than I really thought initially; the VideoSuiteInterface -approach worked after all. All it took was to use it properly. Here are the full sources should anyone want to try it themselves.
player.h:
#ifndef PLAYER_H
#define PLAYER_H
#include <QObject>
#include <maemo-meegotouch-interfaces/videosuiteinterface.h>
class Player : public QObject {
Q_OBJECT
private:
VideoSuiteInterface* videosuite;
public:
Player(QObject *parent = 0);
Q_INVOKABLE void play(QString url);
};
#endif // PLAYER_H
player.cpp:
#include "player.h"
#include <QObject>
#include <QStringList>
#include <QtDeclarative>
Player::Player(QObject *parent) : QObject(parent) {}
void Player::play(QString url) {
QList<QVariant> args;
QStringList urls;
urls << url;
args.append(urls);
videosuite = new VideoSuiteInterface();
videosuite->play(urls);
}
In addition you may want to connect some signals to make the UI more responsive, but basically that should do the trick.
Finally, you need to remember to add following to your .pro file and you are good to go:
CONFIG += videosuiteinterface-maemo-meegotouch

Clean up before closing the QCoreApplication

I have a console-based QCoreApplication which has timers and does socket communication and also uses locked mutex.
When I close the application manually, it gives error saying some mutex is locked and it is timed out. Is there any way I can do clean up in a console application when user closes it?
Cleanup should be handled by destructors and child-parent relationship.
Make your master object (the one in the main) a child of QApplication so it is destructed with all its childs before QApplication is.
Are you sure you killed all your threads? If it is a thread with an eventloop be sure to call QThread::quit() to exit the eventloop before you call QThread::wait()
You can also use the void QApplication::qAddPostRoutine ( QtCleanUpFunction ptr )
to do some special cleanup.
For debugging those messages you can use QtMsgHandler qInstallMsgHandler ( QtMsgHandler h ) and write your own message handler to capture those warnings. If you can simulate the problem you can set a breakpoint on the message and see on the stack where the message is coming from.
void debugMessageHandler( QtMsgType type, const char *msg ){
if(QString(msg).contains( "The message you can see in the console" )){
int breakPointOnThisLine(0);
}
switch ( type ) {
case QtDebugMsg:
fprintf( stderr, "Debug: %s\n", msg );
break;
case QtWarningMsg:
fprintf( stderr, "Warning: %s\n", msg );
break;
case QtFatalMsg:
fprintf( stderr, "Fatal: %s\n", msg );
abort();
}
}
In order to clean up with destructor and child-parent relation ship you can catch the console close signal and call QCoreApplication::exit() to the application instance.
#include <csignal>
#include <QtCore/QCoreApplication>
using namespace std;
struct CleanExit{
CleanExit() {
signal(SIGINT, &CleanExit::exitQt);
signal(SIGTERM, &CleanExit::exitQt);
signal(SIGBREAK, &CleanExit::exitQt) ;
}
static void exitQt(int sig) {
QCoreApplication::exit(0);
}
};
int main(int argc, char *argv[])
{
CleanExit cleanExit;
QCoreApplication a(argc, argv);
return a.exec();
}
Turns out that closing command line application (checked on Win7 & VS2010) by pressing 'close' (red x button on title bar) passes the STATUS_CONTROL_C_EXIT signal to the application. All threads are aborted with this code.
The thread 'Main Thread' (0x980) has exited with code -1073741510
(0xc000013a).
The thread 'QThread' (0x2388) has exited with code
-1073741510 (0xc000013a).
That means that there is no way to intercept this with the QCoreApplication::aboutToQuit() signal.
Take a look at winnt.h or ntstatus.h. That is the value assigned to the
manifest constant STATUS_CONTROL_C_EXIT. The runtime is just
choosing to end your program with the code to note the user's cancel
operation.
you can connect to QCoreApplication::aboutToQuit signal and do the necessary clean up there.

Resources