[SOLVED] Application sometimes(!) crashes

Wurgl

I have here a rather "complex" example:

#include <QtWidgets/qapplication.h>
#include <QtWidgets/qdialog.h>

class MyMainWindow : public QDialog
{
public:
    MyMainWindow();
    virtual ~MyMainWindow();
};

MyMainWindow::MyMainWindow()
    : QDialog()
{
    setWindowTitle(tr("MyMainWindow - Crash"));
}

MyMainWindow::~MyMainWindow()
{
}

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    app.connect(&app, SIGNAL(lastWindowClosed()), &app, SLOT(quit()));

    MyMainWindow *theWindow = new MyMainWindow();
    theWindow->show();
    app.exec();

    exit(0);
}

compiled on OpenSuse 13.2 with
g++ -c -g -fPIC -Wall -W -Wextra -I /usr/include/qt5 main.cpp -o gmain.o
g++ gmain.o -g -L/usr/lib64 -lQt5Gui -lQt5Widgets -lQt5Core -o gcrash

The only thing I do, is starting that program and press ESC to stop it. After doing this a few times, the program dumps core.

$ ./gcrash
$ ./gcrash
$ ./gcrash
$ ./gcrash
$ ./gcrash
Segmentation fault (core dumped)
$ ./gcrash
$ ./gcrash
$ ./gcrash
$ ./gcrash
$ ./gcrash
Segmentation fault (core dumped)

This is all, what gdb tells me.
(gdb) where
#0 0x00007fcdf50aebd9 in ()
#1 0x0000000000000000 in ()
(gdb) disassemble 0x00007fcdf50aebd9
No function contains specified address.

I have no idea how to fix this. I have even no idea how this strange address is reached, it seems that it happens in some cleanup-code in exit() or similar.

Misty River

Segmentation fault is when you try to access memory that you're not allowed or outside userspace.. my best guest is that you have a defective pointer in your myWindow class.. if it's not in one of the function you're probably trying to delete a member that's already been deleted by Qt hierarchy mechanism.. if you really can't find in your code compile with debug symbols and run it in gdb.. if memory serves me right you type backtrace in gdb to get call stack and then you can move between frames.. with symbols you see immediately where the crash occurs... post your myWindow code....

Wurgl

Since I can reduce the code to reproduce the crash even more to this size:

#include <QtWidgets/qapplication.h>
#include <QtWidgets/qdialog.h>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    app.connect(&app, SIGNAL(lastWindowClosed()), &app, SLOT(quit()));

    QDialog *theWindow = new QDialog();
    theWindow->show();
    app.exec();

    exit(0);
}

It is so simple, but shows the same crashes

Wurgl

When I add "sleep(1);" just before the call of "exit(0);", then I see no more crash.

"ps" shows me, that there are two threads running. So it smells like a problem with synchronization of those threads.

BTW: valgrind does not show any problem. But valgrind slows down the program, so it may have the same effect like the call to "sleep()".

Rondog

I don't know if this is related but I have a couple of observations. Q_OBJECT is missing and some odd things in main().

class MyMainWindow : public QDialog
{
Q_OBJECT
public:
...
int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    // app.connect(&app, SIGNAL(lastWindowClosed()), &app, SLOT(quit()));

    MyMainWindow *theWindow = new MyMainWindow();
    theWindow->show();
    return app.exec();

   // exit(0);
}

Wurgl

exit() vs. return seems to cause the problem.

The only difference I see, is that exit() does not delete the QApplication object, wheras a return deletes it.

Hmm … changing app to a pointer and delete that pointer before the call to exit works too.

Strange! Very strange! All that exit() worked fine with qt4, so I did not even think that this could be a problem.

However, thanks!

SGaist

Hi,

Technically the last line should be something like return app.exec();

Wurgl

@SGaist

I disagree. I do this, because I decide which exitcode the application returns to the shell.

A code sniplet like
if(app.exec())
return 42;
might be correct as any other value.

SGaist

Sorry, my message was incomplete. I wanted to say that with calling exit you were probably hitting the data races part from exit.

You're indeed free to return whatever value you want after exec has returned.