Error handling (Linux, Qt 5.15)

[qAlexKo]

A problem with error handling (Linux, Qt 5.15)
I came to Linux and Qt from Windows and have always used try/catch C++ contructions. But it seems Qt wants another way of error handling. For instance, this example doesn't work (the application uncontrollably ends, actually crashes).

void Tmq_blf::on_actionException_test_triggered()
{
    try {
    int *tt = NULL;
    *tt  = 123;
    }

    catch (...) {
     QMessageBox bx; bx.setText("exp show");
     bx.exec();
    }
}
//------------------

How should I handle it correctly in Qt? Is a pointer checking the only way to fight with errors like this (access violation is not necessary a NULL pointer)?

[jsulm]

@qAlexKo The code you posted has nothing to do with Qt.
Such errors can't be handled using try...catch, doesn't matter if Qt app or not.

[qAlexKo]

@jsulm said in Error handling (Linux, Qt 5.15):

Such errors can't be handled using try...catch, doesn't matter if Qt app or not.

It doesn't matter? CBuilder C++ (2002) treated it well however. This example works.

void __fastcall TForm1::Button1Click(TObject *Sender)
{
    try {
    int *tt = NULL;
    *tt  = 123;
    }

    catch (...) {
     ShowMessage("exp show");
    }
}

Or you meant Linux C++ programming in general?

[jsulm]

@qAlexKo With GCC this does not work. You can try with a plain C++ application without Qt.

[JonB]

@qAlexKo
For a start it depends on whether Linux or Windows. Linux for sure not. Windows uses SEH and may have its own ways. Then you're probably down to compiler as to whether it works with that. It's certainly "undefined behaviour" in C++. And still has nothing to do with Qt. But OOI with your "CBuilder" what exception did that catch?

[qAlexKo]

@JonB said in Error handling (Linux, Qt 5.15):

. But OOI with your "CBuilder" what exception did that catch?

EAccessViolation

[JonB]

@qAlexKo OK, if you Google you'll find it's totally Borland/Embarcadero/C++B specific. "Proper" C++ prefers to let you shoot yourself in the foot :)

[qAlexKo]

@JonB said in Error handling (Linux, Qt 5.15):

it's totally Borland/Embarcadero/C++B specific

So, as I see, in Linux Qt there is no standard way to prevent apps from crashing in case of access violation. And a sudden disappearance of a program from the screen is a trifle, a matter of life. It is a pity however the user cannot tell the programmer what errror was. :)

[SGaist]

@qAlexKo hi,

As already explained, it has nothing to do with Qt.

It's compiler specific. In this case: CBuilder VS gcc.

[Kent-Dorfman]

@qAlexKo said in Error handling (Linux, Qt 5.15):

So, as I see, in Linux Qt there is no standard way to prevent apps from crashing in case of access violation. And a sudden disappearance of a program from the screen is a trifle, a matter of life. It is a pity however the user cannot tell the programmer what errror was. :)

Allowing a null pointer exception/trap to occur is an indication of poor programming. It is expected that the professional programmer understand that dereferencing a null pointer is a fatal error.

For ignoring the the correct and sophisticated path of coding to prevent such errors, there is the fallback of catching the POSIX signal SIGSEGV that is triggered by the illegal instruction. I would fire anyone on my staff who attempted such nonsense.

[qAlexKo]

@Kent-Dorfman said in Error handling (Linux, Qt 5.15):

Allowing a null pointer exception/trap to occur is an indication of poor programming. It is expected that the professional programmer understand that dereferencing a null pointer is a fatal error.
For ignoring the the correct and sophisticated path of coding to prevent such errors, there is the fallback of catching the POSIX signal SIGSEGV that is triggered by the illegal instruction.

You read unattentively - access violation is not nessesary follows a NULL pointer. And all I wanted is to learn a way to prevent my (QtCreator) program from crashing just in case. Bugs sometimes happen, you see - you are a bad programmer if you state the opposite.
You wrote about " there is the fallback of catching the POSIX signal SIGSEGV that is triggered by the illegal instruction" - please can you give me an example using my example: int *tt = NULL; *tt = 123;. Treat the error from my example in that way and show me your professionalism. Thank you.

[qAlexKo]

I found a way which can help save the app critical data in case access vioation.

header:

#ifndef MAINWINDOW_H
#define MAINWINDOW_H

#include <signal.h>
#include <QMainWindow>
#include <QMessageBox>
#include <QString>

QT_BEGIN_NAMESPACE
namespace Ui { class MainWindow; }
QT_END_NAMESPACE

class MainWindow : public QMainWindow
{
    Q_OBJECT

public:
    MainWindow(QWidget *parent = nullptr);
    ~MainWindow();

private slots:
    void on_bt_cause_mem_err_clicked();

private:
    Ui::MainWindow *ui;
};
#endif // MAINWINDOW_H

The code:

#include "mainwindow.h"
#include "ui_mainwindow.h"

struct sigaction sa;
int save_data_to_disk()
{
  QMessageBox mb; mb.setText("App abnormal ending - your data has been saved to disk"); mb.exec();
  mb.setText("Critical vars are this: xxx, xxx, xxx, xxx"); mb.exec();
}
//---------------------------------
void segfault_sigaction(int signal, siginfo_t *si, void *arg)
{
    save_data_to_disk();
   throw "close";                 //without it the error can persist
}
//---------------------------------
MainWindow::MainWindow(QWidget *parent)
    : QMainWindow(parent)
    , ui(new Ui::MainWindow)
{
    ui->setupUi(this);
    memset(&sa, 0, sizeof(struct sigaction));
    sigemptyset(&sa.sa_mask);
    sa.sa_sigaction = segfault_sigaction;
    sa.sa_flags   = SA_SIGINFO;
    sigaction(SIGSEGV, &sa, NULL);
}
//------------------------------------
MainWindow::~MainWindow()
{ delete ui; }
//------------------------------
void MainWindow::on_bt_cause_mem_err_clicked()
{
    int *tt = NULL;
    *tt  = 123;
}
//------------------------------

This handling prevents data damages, but still the program cannot run further on. :-\ ;-)

[JonB]

@qAlexKo

void segfault_sigaction(int signal, siginfo_t *si, void *arg)
{
    save_data_to_disk();
   throw "close";                 //without it the error can persist
}

This is called "out of the frying pan into the fire"!

Neither of these statements is safe to execute from within a signal handler. Have you read up about this?

[Kent-Dorfman]

@qAlexKo said in Error handling (Linux, Qt 5.15):

You read unattentively - access violation is not nessesary follows a NULL pointer. And all I wanted is to learn a way to prevent my (QtCreator) program from crashing just in case. Bugs sometimes happen, you see - you are a bad programmer if you state the opposite.
You wrote about " there is the fallback of catching the POSIX signal SIGSEGV that is triggered by the illegal instruction" - please can you give me an example using my example: int *tt = NULL; *tt = 123;. Treat the error from my example in that way and show me your professionalism. Thank you.

but no, dereferencing a null pointer IS an access violation on most modern architectures. While it is true that according to the language standards, it is undefined behaviour, the implementation of most virtual memory system machines triggers a SIGSEGV on such an operation.

For creating an example: nope. There are plenty of online examples that show how to create signal handlers, and in presenting one, I would be encouraging behaviour (in this specific case) that I don't agree with. Sorry.

I will tell you how to avoid your problem:

int myVar;
int* const tt = &myVar; // prohibits changing the value of the tt pointer
*tt = 1234;

To repeat, take steps to avoid dereferencing null pointers. Don't expect the machine to clean up after you.

[JonB]

@Kent-Dorfman
But this doesn't protect if code might go:

*(int *)tt = 1234;    // or const_cast<int *>(tt) if that works here

;-)

[qAlexKo]

@JonB said in Error handling (Linux, Qt 5.15):

throw "close"; //without it the error can persist
}

This is called "out of the frying pan into the fire"!
Neither of these statements is safe to execute from within a signal handler. Have you read up about this?

Yes, the application will crash anyway, but as I showed you can save some important data before crashing..

[JonB]

@qAlexKo said in Error handling (Linux, Qt 5.15):

but as I showed you can save some important data before crashing..

No, you can't! In the sense that you are not allowed/supposed to call what save_data_to_disk() will do from within a signal handler. Go read up! You are very restricted as to what is allowed, not much more than setting a flag variable. All the stuff you are going to do inside that "save" --- Qt UI stuff, writing to disk etc. --- is not safe to do inside a signal handler. It might work, or might not, it might write rubbish to your file, whatever. The fact that you might find it works when you test in your environment is "luck". Up to you whether you want to read up and take heed.

[qAlexKo]

In the final, I can only once again to express my disappointment that Linux QtCreator doesn't provide standard means to make a big stable application. A big application as rule consists of many different branches and they can be independent, in a big extent. If one task has a hidden bug it, IMHO, must mean that the app must not crash and the other app branches must be able to continue their work after handling the error. In short Linux QT must learn how to handle any errors that can happen theoretically. Then a system can be called reliable.
You can say that sea ships must not get shell-holes and perfect captains must prevent such from happening. But reliable ships have partition walls, bilge pumps, means for hadnling shell-holes and even lifeboats. ;-)

[JonB]

@qAlexKo
We have tried to explain to you that it has nothing to do with Qt libraries or Qt Creator.

Maybe you could/should auto-save your valuable data on a regular timer, when the application is in a safe and consistent state?

[qAlexKo]

@JonB said in Error handling (Linux, Qt 5.15):

We have tried to explain to you that it has nothing to do with Qt libraries or Qt Creator.
Maybe you could/should auto-save your valuable data on a regular timer, when the application is in a safe and consistent state?

Well, actually, as we see QT can handle these severe errors, but on the primitive level. So it certainly has something with QT library.

As for constant saving of important data, yes is is also the way, but it is not as elegant as try/catch in Delphi/CBuilder during every attempt to do sometning with memory. I think memory manager must know the limits of allocated memory.