How to show a message to user when app crashes

[INeedADollar]

You will probably need to do something like the following:

In main(), call QApplication::setQuitOnLastWindowClosed() with the value false before you show the mainWindow. This is to prevent what happens in the signal handler (see below) from causing the app to quit too soon.

In your signal handler, call QApplication::closeAllWindows() first, using the global qApp pointer.
Next, display your QMessageBox.
When the user closes the message box, call QApplication::quit() and then exit the handler.

You might also need to add a call to QApplication::quit() after app.exec() in main, but probably not since main() exits at that point anyway.

Another option would be to define your mainwindow pointer as a global variable in main.cpp so you can get to it from your signal handler. The all you have to do is call mainwindow->hide() from inside the handler before you display your message box. You should probably also call QApplication::quit() after the message box is closed so Qt can have a chance to clean up instead of just crashing out.

Thank you very, very much! The second method worked very well. You are the best!

[d_stranz]

The second method worked very well. You are the best!

It may not work so well if you have a modal dialog window open when a SIGSEGV happens - hiding the main window may not hide the dialog.

You could test this by adding a QDialog-based class to your app and override some event (like showEvent()) for the class. In that event, call "raise( SIGSEGV )" to trigger a segmentation fault signal, which should go into your handler. If hiding the main window also hides the dialog, all is good.

[INeedADollar]

It may not work so well if you have a modal dialog window open when a SIGSEGV happens - hiding the main window may not hide the dialog.

You could test this by adding a QDialog-based class to your app and override some event (like showEvent()) for the class. In that event, call "raise( SIGSEGV )" to trigger a segmentation fault signal, which should go into your handler. If hiding the main window also hides the dialog, all is good.

I have a problem. I cannot do this because QDialog also has a function named raise() but without any arguments and I cannot call the function raise(SIGSEGV) from signal.h
Do you know how can I call it without any error?

P.S. the error is "too many arguments for function call". I think the compiler confuses the functions.

[d_stranz]

Do you know how can I call it without any error?

You need to remember your C++ basics. To call a non-member function, eg. one in the global namespace, you use the global scope qualifier:

::raise( SIGSEGV );

::raise( SIGSEGV );

To copy to clipboard, switch view to plain text mode 

[INeedADollar]

You need to remember your C++ basics. To call a non-member function, eg. one in the global namespace, you use the global scope qualifier:

::raise( SIGSEGV );

::raise( SIGSEGV );

To copy to clipboard, switch view to plain text mode 

Thank you very much! Not all windows closed when signal was sent, but I wrote this part inside signalHandler() function before showing the QMessageBox:

const QWidgetList topLevelWidgets = QApplication::topLevelWidgets();
 for (QWidget *widget : topLevelWidgets) {
        widget->hide();
 }

const QWidgetList topLevelWidgets = QApplication::topLevelWidgets();
 for (QWidget *widget : topLevelWidgets) {
        widget->hide();
 }

To copy to clipboard, switch view to plain text mode 

Now it is working very well. Thank you again!

[d_stranz]

Great! Now start practicing defensive programming and debug your programs before you release them so you will never have a need for this kind of message.

If you want to make this kind of signal handler really useful instead of just displaying a message like "Oops, something broke and there is nothing you can do to fix it", you would implement something in your QApplication class that could save any open files and basically try to do whatever is possible to clean up what the user was doing and leave it in a recoverable state.

Just displaying a message and then crashing out isn't much different from simply crashing out as far as the user is concerned if their work is trashed and they lose it all.

[INeedADollar]

Great! Now start practicing defensive programming and debug your programs before you release them so you will never have a need for this kind of message.

If you want to make this kind of signal handler really useful instead of just displaying a message like "Oops, something broke and there is nothing you can do to fix it", you would implement something in your QApplication class that could save any open files and basically try to do whatever is possible to clean up what the user was doing and leave it in a recoverable state.

Just displaying a message and then crashing out isn't much different from simply crashing out as far as the user is concerned if their work is trashed and they lose it all.

What a great idea! You are right, it is much better when the app saves your progress automatically If it crashes. Thank you for reminding me of this!

[cyberopsinfosec]

Hello,

I can't find correct solution still.

Thanks & Regards

Cyberops Infosec LLP

[d_stranz]

I can't find correct solution still.

What is your question? If you are trying to implement something in the same way as INeedADollar is doing, then there is more than enough information in the code and advice that has been posted in response to his questions for you to do the same thing.