Crash adding QVBoxLayout to QDialog

Binary91

Hi,

I don't understand the problem why my program crashes when I try to add a new QVBoxLayout to my QDialog.

This is my header:

class myQDialog : public QDialog
{
    Q_OBJECT

private:
    QTabWidget *twMain;
    QWidget *tabDataOne, *tabDataTwo, *tabDataThree;
    QVBoxLayout *layDataOne, *layDataTwo, *layDataThree;

public:
    myQDialog(QWidget *parent = nullptr);
    ~myQDialog();
};

And the source:

myQDialog::myQDialog(QWidget *parent) : QDialog(parent)
{
    setWindowTitle("Setup");
    twMain = new QTabWidget(this);
    twMain->setSizePolicy(QSizePolicy::MinimumExpanding, QSizePolicy::MinimumExpanding);

    tabDataOne = new QWidget(twMain);
    layDataOne = new QVBoxLayout;                 // <--- program crashes here
    tabDataOne->setLayout(layDataOne);

/*
...
*/
}

myQDialog::~myQDialog()
{

}

I can not explain where the problem is. I use the same code in my QMainWindow and there it works. Maybe there is a problem using it inside a QDialog?

Thank you for your help in anticipation.

Binary91

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

layDataOne = new QVBoxLayout; // <--- program crashes here

I would doubt there is actually any "crash" on this precise line, since it does nothing other than a new assigned to a variable. I suppose it is possible it might have a problem on the following line since you are still inside the constructor, but so far as I recall that should be fine.

Compile for debug, let it "crash", examine the stack view window carefully to see just where it crashes and maybe why.

One thought: tabDataOne = new QWidget(twMain). For the widgets on a QTabWidget maybe just setting parent is not right/enough. You are supposed to call int QTabWidget::addTab(QWidget *page, const QString &label) to properly add the widget as an actual tab. Try tabDataOne = new QWidget; [Other stuff to tabDataOne here...] twMain->addTab(tabDataOne, "...") instead, then I think all will go through.

Ah yes, I see in https://doc.qt.io/qt-6/qtabwidget.html#details

Create a QTabWidget.

Create a QWidget for each of the pages in the tab dialog, but do not specify parent widgets for them.

Insert child widgets into the page widget, using layouts to position them as normal.

Call addTab() or insertTab() to put the page widgets into the tab widget, giving each tab a suitable label with an optional keyboard shortcut.

Note how #2 says but do not specify parent widgets for them.

Binary91

@JonB Hi,
thank you for your fast reply. Embarrassing, but I found the mistake: I forgot to call the open() function for the myQDialog object before showing it :-)

Well, addressing what you wrote:
Thank you for that hint. Is it a general rule not to specify parents for objects that I addor setto a tabor layout? Is it reliable that those functions (e. g. addTab(), setLayout) set the parent automatically?

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

I forgot to call the open() function for the myQDialog object before showing it :-)

I have no idea how that would cause a crash, or on the line you said it did. For one thing, this is during the dialog constructor, so no "open" or "showing" can be executed till after it has finished....

Yes, functions like addTab() or setLayout() deal with setting parentage for you, so you do not have to if you are going to use those. It can/may be a little more efficient not to do so: creating a widget with a parent does some work on the parent (or the widget, or both, I can't remember, may apply only to adding widgets not layouts) to do with layout, then when you later e.g. set a layout on the parent and place the sub-widget on that layout it has to do new work undoing the earlier work.

Having said that, I don't think it's a big deal or leads to "crashes". I don't know whether there is an issue about setting the parent on a QWidget which is to go into a QTabWidget via addTab(), not sure where your crash came from, I would just follow what the docs say to do.

Binary91

@JonB Alright, thank you!

Binary91

Ok, nope, I still have problems with it. I cannot add a fifth layout layMainto my class!

The following works fine in the header (without initializing it):
Header:

class myQDialogUseraccountRegistrationSetup : public QDialog
{
    Q_OBJECT

private:
    QTabWidget *twMain;
    QWidget *tabDataPersonal, *tabDataContact, *tabDataLogin, *tabDataBanking;
    QVBoxLayout *layDataPersonal, *layDataContact, *layDataLogin, *layDataBanking, *layMain;

public:
    myQDialogUseraccountRegistrationSetup(QWidget *parent = nullptr);
    ~myQDialogUseraccountRegistrationSetup();
};

Src:

myQDialogUseraccountRegistrationSetup::myQDialogUseraccountRegistrationSetup(QWidget *parent) : QDialog(parent)
{
    setWindowTitle("Registration Setup");

    twMain = new QTabWidget;

    tabDataPersonal = new QWidget;
    layDataPersonal = new QVBoxLayout;
    tabDataPersonal->setLayout(layDataPersonal);
    twMain->addTab(tabDataPersonal, "Personal");

    tabDataContact = new QWidget;
    layDataContact = new QVBoxLayout;
    tabDataContact->setLayout(layDataContact);
    twMain->addTab(tabDataContact, "Contact");

    tabDataLogin = new QWidget;
    layDataLogin = new QVBoxLayout;
    tabDataLogin->setLayout(layDataLogin);
    twMain->addTab(tabDataLogin, "Login");

    tabDataBanking = new QWidget;
    layDataBanking = new QVBoxLayout;
    tabDataBanking->setLayout(layDataBanking);
    twMain->addTab(tabDataBanking, "Banking");
}

Instead, when I declare layMainat the first position of all the layouts, the program crashes without debugging info again:

class myQDialogUseraccountRegistrationSetup : public QDialog
{
    Q_OBJECT

private:
    QTabWidget *twMain;
    QWidget *tabDataPersonal, *tabDataContact, *tabDataLogin, *tabDataBanking;
    QVBoxLayout *layMain, *layDataPersonal, *layDataContact, *layDataLogin, *layDataBanking;

public:
    myQDialogUseraccountRegistrationSetup(QWidget *parent = nullptr);
    ~myQDialogUseraccountRegistrationSetup();
};

Well, why?
Second question: In case 1 where it works, it is not possible for me to initialize the layMaindoesn't matter at which position in the constructor...

Is the matter a reason of the order? I don't understand it..

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

Ok, nope, I still have problems with it. I cannot add a fifth layout layMainto my class!

You seem to be saying the code you show does not "crash", but if you make a change it does. Please show code which crashes, not code which works! [Update: Yes, I may have misunderstood what you are saying here.] (And preferably a minimal example, i.e. the *minimum needed to reproduce: here do you really think it is necessary to have five layouts with 4 tabs before there is an issue, I doubt it?) You do not show any attempt to set layMain or add it in your code, as you can ascertain by searching what you have pasted, so who knows. Maybe it's an uninitialized pointer, I don't know. That is the case in the code you show.

In any case, what does "the program crashes without debugging info again" mean, what did you do about running it under the debugger with:

Compile for debug, let it "crash", examine the stack view window carefully to see just where it crashes and maybe why.

[Because I may have misunderstood what you are saying, please start with this to discover where you say it "crashes".]

On a separate matter, the code as shown does not place the QTabWidget on the dialog. Why not?

Binary91

Well,

I realized that the problem must be the combination of my QDialog with my simultaniously showed QMainWindow.

I separated the QDialog class into a new, empty project and everything works fine..

I cannot post the whole project code, but maybe you see an error in my main file:

#include <QDebug>
#include <QApplication>
#include <QDir>
#include <QSqlDatabase>
#include <QSqlError>
#include "clsConfigMain.h"
#include "clsWindowMain.h"
#include "myQDialogUseraccountRegistration.h"

int main(int argc, char *argv[])
{
    QApplication App(argc, argv);
    clsConfigMain configMain;
    if(configMain.criticalError())
    {
        QMessageBox::critical(nullptr, "Critical error", "A critical error occured while trying to load the main configuration. The program will exit...");
        return 1;
    }
    clsWindowMain winMain(configMain);
    winMain.showMaximized();
    myQDialogUseraccountRegistrationSetup winURS(&winMain);
    winURS.open();
    int iRet = App.exec();
    qDebug() << iRet;
    return iRet;
}

I think the problem is that I define a QDialog object with the QMainWindow as parent. Hm..

mpergand

@Binary91 said in Crash adding QVBoxLayout to QDialog:

myQDialogUseraccountRegistrationSetup winURS(&winMain);

You set a parent to a local instance, may lead to a double delete when winUrs runs out of scope.

This line is suspicious:
clsWindowMain winMain(configMain);
is configMain parent of winMain ?

Run your app in debug mode !

JonB

@Binary91 :

@mpergand said in Crash adding QVBoxLayout to QDialog:

Run your app in debug mode !

@JonB said in Crash adding QVBoxLayout to QDialog:

In any case, what does "the program crashes without debugging info again" mean, what did you do about running it under the debugger with:

Compile for debug, let it "crash", examine the stack view window carefully to see just where it crashes and maybe why.

Binary91

@mpergand said in Crash adding QVBoxLayout to QDialog:

You set a parent to a local instance, may lead to a double delete when winUrs runs out of scope.

Yes, I think that is the problem. Well, I'm asking myself about the best way to deal with a QDialog in a program where I have a QMainWindow. Should I declare the MainWindow as a parent or should I call the QDialogs independentelly?
Second, I'm asking myself if it's better to call the QDialog with exec() or with open(). Documentation says I should try to avoid using exec(), but I see no alteranative to pause the event loop until the QDialog is finished and I need the program to pause until it is finished, I guess it is very often the purpose of QDialogs, isn't it?

JonB

@Binary91
Have advised you several times already, as has @mpergand, to compile for debug, run under debugger and look at/show us the stack view when it crashes. Is there a particular reason you simply ignore this and continue to "guess" each time what might be wrong? Do you not want to help yourself/us?

In itself there is no problem having QDialog with a QMainWindow or setting that to its parent. @mpergand suggested you might have problem because of the way you choose to use stack rather than heap variables for your windows/dialogs and their parentage, and that this may be problematic.

I wonder about something else. You are using winMain as the parent of a dialog which you open(). However at that moment winMain has not actually been shown yet --- the showMaximized() only marks it for showing, the showing does not happen until the start of App.exec(). That means the dialog has a "non-shown" parent, and I wonder if that would not cause a problem.

Ignore what the docs say about not using QDialog::exec(). That is the right thing to use if you want to show a modal dialog, i.e. one which blocks till the user exits it.

I see no point in trying to open a modal dialog with main window as parent if you are going to show it (open() or exec()) prior to showing the main window itself. In particular if you want it to be modal. I suggest you do one of the following:

Assuming you want the modal dialog to come up before you show the main window, use winURS.exec() but do not create via winURS(&winMain);, just plain winURS;. Does removing that parentage make it OK?
If you do not want the dialog to appear till after the main window has been shown, and maybe use that main window for its parent, override showEvent() in your clsWindowMain , call the base implementation there first so that it gets shown, and only then create and show the dialog.

Binary91

@JonB said in Crash adding QVBoxLayout to QDialog:

Have advised you several times already, as has @mpergand, to compile for debug, run under debugger and look at/show us the stack view when it crashes. Is there a particular reason you simply ignore this and continue to "guess" each time what might be wrong? Do you not want to help yourself/us?

Sorry for the belated response, had no time to answer earlier.
No, I'm interested in helping myself and us understanding the problem I have. I'm simply not used to the debugger, but I tried it now again:
At first, a MessageBox appears in front as far as the program crashes. There it says (translated): "The process was stopped due to a signal of the operating system. Name of the signal: SIGSEGV. Meaning: Segmentation fault."
Then, in the window on the bottom left, I have the following text:

Well, I'm happy to hear that it was totally ok to use QDialog::exec() for my purposes. I don't know why documentation recommends to avoid that.

"I wonder about something else. You are using winMain as the parent of a dialog which you open(). However at that moment winMain has not actually been shown yet --- the showMaximized() only marks it for showing, the showing does not happen until the start of App.exec(). That means the dialog has a "non-shown" parent, and I wonder if that would not cause a problem."
It is shown directly in the constructor.

" @mpergand suggested you might have problem because of the way you choose to use stack rather than heap variables for your windows/dialogs and their parentage, and that this may be problematic."
Shouldn't I do so? You mean all my widgets inside the QDialog? In the docu, in most examples the QWidgets are created that way, aren't they?

jsulm

@Binary91 What is in line 82 in myQDialogUseraccountRegistrationSetup::myQDialogUseraccountRegistrationSetup? That's the line causing the crash according to the stack trace.

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

It is shown directly in the constructor.

What is shown in what constructor?

In any case, before going any further you need to answer @jsulm's question. The beauty of you having produced a stack trace is that we don't have to guess what might be wrong, we can (hopefully) determine from the trace.

Binary91

@jsulm said in Crash adding QVBoxLayout to QDialog:

What is in line 82 in myQDialogUseraccountRegistrationSetup::myQDialogUseraccountRegistrationSetup? That's the line causing the crash according to the stack trace.

It is the command where I set the main layout:

myQDialogUseraccountRegistrationSetup::myQDialogUseraccountRegistrationSetup(QWidget *parent) : QDialog(parent)
    {
        twMain = new QTabWidget;
    
        tabDataPersonal = new QWidget;
    
        cbDPName = new QCheckBox("Name", tabDataPersonal);
        cbDPPrename = new QCheckBox("Vorname");
        cbDPMiddleNames = new QCheckBox("Zwischennamen");
        cbDPDoB = new QCheckBox("Geburtsdatum");
        cbDPGender = new QCheckBox("Geschlecht");
        cbDPNationality = new QCheckBox("Nationalität");
        layDataPersonal = new QVBoxLayout;
        layDataPersonal->addWidget(cbDPName);
        layDataPersonal->addWidget(cbDPPrename);
        layDataPersonal->addWidget(cbDPMiddleNames);
        layDataPersonal->addWidget(cbDPDoB);
        layDataPersonal->addWidget(cbDPGender);
        layDataPersonal->addWidget(cbDPNationality);
        tabDataPersonal->setLayout(layDataPersonal);
        twMain->addTab(tabDataPersonal, "Persofnalien");
    
        cbDCStreet = new QCheckBox("Strasse");
        cbDCHouseNr = new QCheckBox("Hausnummer");
        cbDCZipCode = new QCheckBox("Postleitzahl");
        cbDCCity = new QCheckBox("Ort");
        cbDCRegion = new QCheckBox("Region/Kanton/Bundesland");
        cbDCState = new QCheckBox("Land");
        cbDCMail = new QCheckBox("E-Mail");
        cbDCPhoneStateCode = new QCheckBox("Ländervorwahl");
        cbDCPhonePrivate = new QCheckBox("Telefon (Privat)");
        cbDCPhoneMobile = new QCheckBox("Telefon (Mobil)");
        cbDCPhoneBusiness = new QCheckBox("Telefon (Arbeit)");
        cbDCFax = new QCheckBox("Fax");
    
        tabDataContact = new QWidget;
        layDataContact = new QVBoxLayout;
        layDataContact->addWidget(cbDCStreet);
        layDataContact->addWidget(cbDCHouseNr);
        layDataContact->addWidget(cbDCZipCode);
        layDataContact->addWidget(cbDCCity);
        layDataContact->addWidget(cbDCRegion);
        layDataContact->addWidget(cbDCState);
        layDataContact->addWidget(cbDCMail);
        layDataContact->addWidget(cbDCPhoneStateCode);
        layDataContact->addWidget(cbDCPhonePrivate);
        layDataContact->addWidget(cbDCPhoneMobile);
        layDataContact->addWidget(cbDCPhoneBusiness);
        layDataContact->addWidget(cbDCFax);
        tabDataContact->setLayout(layDataContact);
        twMain->addTab(tabDataContact, "Kontaktdaten");
    
        tabDataLogin = new QWidget;
        layDataLogin = new QVBoxLayout;
        tabDataLogin->setLayout(layDataLogin);
        twMain->addTab(tabDataLogin, "Logindaten");
    
        tabDataBanking = new QWidget;
        layDataBanking = new QVBoxLayout;
        tabDataBanking->setLayout(layDataBanking);
        twMain->addTab(tabDataBanking, "Zahlungsinformationen");
    
        layMain = new QVBoxLayout;
        layMain->addWidget(twMain);
        this->setLayout(layMain);  // <-- line #82
        setWindowTitle("Registration Setup");

From where did you know that it was line 82? How do I interpret the debugger text? And back to my problem: What am I doing wrong? When I use the same code in a separate project without a MainWindow, everything works just fine..

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

From where did you know that it was line 82?

By looking at the screenshot you show of the stack trace. In the "Zeile" column, which I suppose means "line" or "row"? And the function name in the "Funktion" column. And "Datei" to apparently tell you the file name. And it's showing the "stack" or "call" trace. You just need to look at it.

It is dying during some "reparenting of child widgets", caused from the final setLayout() causing this to adopt the whole widget hierarchy. Slightly strange error, not yet sure whether it's your code or something in Qt.

One thing I notice is:

cbDPName = new QCheckBox("Name", tabDataPersonal);

right at the start. All the others you do not pass a QWidget as parent. Try making this one the same, remove the , tabDataPersonal. Any difference?

Otherwise there are too many widgets for me to work through. Comment out all those new QCheckBox lines and most importantly the addWidget()s. Does that make it work? Or, build up from just

        layMain = new QVBoxLayout;
        // layMain->addWidget(twMain);
        this->setLayout(layMain);  // <-- line #82

Nothing else. Does that work? Add the QTabWidget back in, add one page, ..., till it goes wrong.

Binary91

@JonB said in Crash adding QVBoxLayout to QDialog:

One thing I notice is:

cbDPName = new QCheckBox("Name", tabDataPersonal);

right at the start. All the others you do not pass a QWidget as parent. Try making this one the same, remove the , tabDataPersonal. Any difference?

I removed that (did not know why I forgot it here), nothing happened.
It is indeed an interesting error. I tried lots of things, even the way you mentioned with out-commenting all the widgets or not setting the layout.
As I mentioned earlier, even only declaring the layMaininside the header causes the crash, when I declare it at the first position of all my layouts inside the class declaration. When I put it at the end of the member declarations and do not define it inside the .cpp, then it will not crash...

As you say, it is a weird error and I can't believe that the code itsself is the problem. When I separate the QDialog into a separate project, it works just fine..

JonB

@Binary91 said in Crash adding QVBoxLayout to QDialog:

As I mentioned earlier, even only declaring the layMain inside the header causes the crash, when I declare it at the first position of all my layouts inside the class declaration. When I put it at the end of the member declarations and do not define it inside the .cpp, then it will not crash...

Hmmm.... In itself, C++ does not care what order you declare your member variables, nor how many you have. Moving them around should have no effect. However: when you create an instance of a class the member variables' area is uninitialized, the variables contain "random" data. And what random value each one contains can indeed be affected by the "coincidences" of where they happen to be in memory, different position => different value. Or same can happen if your code (somehow) "overruns"/"underruns" and writes into the instance's variables' storage area....

One thing: when you change the order of member variables it is vital that all modules using the class be recompiled. Make sure you delete all files in the build output (not source!) directory, re-run qmake, re-run the build. It would also be interesting to test whether if you compile for release versus for debug the behaviour changes?

Since you say behaviour varies according as layMain is first or last among the declarations, try something like:

QVBoxLayout *dummy1, *dummy2, *dummy3, *dummy4;
QVBoxLayout *layDataPersonal, *layDataContact, *layDataLogin, *layDataBanking, *layMain;
QVBoxLayout *dummy5, *dummy6, *dummy7, *dummy8;

moving the *layMain within its line as you please. This gives some "dummy space" on either side of these variables in the class's layout. Does this affect the error behaviour?

Also try moving the winURS from the stack to the heap in your main():

    myQDialogUseraccountRegistrationSetup *winURS = new myQDialogUseraccountRegistrationSetup;
    winURS->open();

Binary91

@JonB said in Crash adding QVBoxLayout to QDialog:

One thing: when you change the order of member variables it is vital that all modules using the class be recompiled. Make sure you delete all files in the build output (not source!) directory, re-run qmake, re-run the build. It would also be interesting to test whether if you compile for release versus for debug the behaviour changes?

Wow, that did the job! I completely deleted the build directory, built the project again and it works without changing anything of the code...

That is interesting, because in the past, I never had to do that and I (really, really often) changed the positions of class members inside the class declaration. I never had such an issue before. Maybe I just had luck till now...

So I have to re-build the project now each time I change anything inside a header file, like modifing member orders in the declaration list?