PDA

View Full Version : Error "has triggered a breakpoint" when trying to call members of QSpinBox in Debug



donelron
15th July 2015, 15:03
Dear all,


I am rather new to Qt and I am working on an application in which I have several ui-files which contain QSpinboxes. Those ui-files were generated while still using Qt 4.8.4-1. Now, I am using 5.4.1 (with Visual Studio 2012 and CMake) and I have observed the following strange behaviour which was not there while still working with Qt 4.8.4-1:
When running the following code in DEBUG mode, then I get a runtime error "... has triggered a breakpoint". It is triggered after leaving the main method. There is no runtime error when running it in RELEASE.




#include <QApplication>
#include <QWidget>
#include <QSpinBox>
#include <qnamespace.h>
#include <QFlags>

int main(int argc, char *argv[])
{
int i=777; //some random value

QApplication app(argc, argv);


QSpinBox *sbxDuration = new QSpinBox();

//Call QSpinBox members
//sbxDuration->setMinimum(1); // causes runtime error "... has triggered a breakpoint"
sbxDuration->setMaximum(2); // does not trigger the runtime error
//sbxDuration->setValue(1); // causes runtime error "... has triggered a breakpoint"
//sbxDuration->setSingleStep(0); // causes runtime error "... has triggered a breakpoint"


//Call QAbstractSpinBox members (none of these calls cause the runtime error)
sbxDuration->setWrapping(true);
sbxDuration->setFrame(true);
QFlags<Qt::AlignmentFlag> flg;
sbxDuration->setAlignment(flg);
sbxDuration->setReadOnly(true);
sbxDuration->setButtonSymbols(QAbstractSpinBox::NoButtons);
sbxDuration->setAccelerated(false);
sbxDuration->setCorrectionMode(QAbstractSpinBox::CorrectToPrevi ousValue);


delete sbxDuration;

return i;

}
// this results in
// "... has exited with code 0 (0x0)." if runtime error occurs
// "has exited with code 777 (0x309)." if no runtime error



I added a new system variable called “_NO_DEBUG_HEAP” with a value of “1” to Control Panel->System Properties->Advanced System Settings->Environment Variables->System Variables (http://stackoverflow.com/questions/6486282/set-no-debug-heap). However, that did not help.
My concern is that even if in my minimal example it seems to be only a problem in DEBUG mode, it will be a problem in the "real" application that I am working on.

Does anybody have an idea how to locate the error?!?

Thanks in advence!

d_stranz
15th July 2015, 23:16
Well, normally, you don't create widgets just floating out in interstellar space and make random calls to member functions like your example does. You make a dialog or a main window, and its constructor takes the ui code and uses it to build the visible UI. Or you create a QWidget instance and call its show() method. And normally, none of this becomes visible until after the event loop is running (app.exec()).

My guess is that because you've created your spin box on the heap and you aren't calling the show() or exec() methods, there's some spin box behavior that depends on one of these prerequisites and thus it blows up. Make a proper Qt GUI application and try again.

donelron
20th July 2015, 15:08
Dear d_stranz,

I posted the minimal example for better overview, however, the problem is still there, if i incorporate it into a "proper GUI application" (see below).

main.cpp:

#include <QApplication>

#include <TestWindow.h>

int main(int argc, char *argv[])
{
int i=777; //some random value

QApplication app(argc, argv);
TestWindow w;
w.show();
i= app.exec();

return i;
}



TestWindow.h:

#ifndef TESTWINDOW_H
#define TESTWINDOW_H

#include <QMainWindow>

namespace Ui {
class TestWindow;
}

class TestWindow : public QMainWindow
{
Q_OBJECT

public:
explicit TestWindow(QWidget *parent = 0);
~TestWindow();

private:
Ui::TestWindow *ui;
};

#endif // TESTWINDOW_H



TestWindow.cpp:

#include "TestWindow.h"
#include "ui_TestWindow.h"

TestWindow::TestWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::TestWindow)
{
ui->setupUi(this);
}

TestWindow::~TestWindow()
{
delete ui;
}



TestWindow.ui:

<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<class>TestWindow</class>
<widget class="QWidget" name="TestWindow">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>400</width>
<height>300</height>
</rect>
</property>
<property name="windowTitle">
<string>Form</string>
</property>
<widget class="QSpinBox" name="spinBox">
<property name="geometry">
<rect>
<x>100</x>
<y>70</y>
<width>42</width>
<height>22</height>
</rect>
</property>
</widget>
</widget>
<resources/>
<connections/>
</ui>



If I run this in DEBUG, then I get the runtime error "..has triggered a breakpoint" as soon as I close the window.
If I replace the QSpinBox with a QLineEdit, then the runtime error at closing of the window disappears.
However, if I add some text to the QLineEdit while the window is open, I get the same error. It seems that the application can not handle it, if any QWidgets (like QLineEdit or QSpinBox) hold data during runtime.

I also noticed that when compiling in DEBUG, I get the warning
"Warning 1 warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification C:\svn\SpielwieseQt\_build_x64_vc11\LINK". Not sure, if this is related to the problem I described.

Any ideas on how to approach this?

d_stranz
20th July 2015, 21:27
When I create a new project and paste your code into the UI file, it runs just fine. This is with VS 2013, Qt 5.4.1. I doubt the VS version has anything to do with it. Are you sure you are linking with the same version of Qt that is loaded at run-time? That is, is your PATH environment variable pointing to the same location for Qt runtime DLLs as you are specifying in your linker options?

donelron
22nd July 2015, 13:41
It turned out that it was a problem with the 5.4.1 build of the lib. Using another build (Qt5.5) solved the problem.

Mr_workalota787
21st May 2020, 03:28
how do you change the build of qt ??

ChrisW67
21st May 2020, 08:25
Use the Maintenance Tool to download a different version of the Qt libraries, or download Qt and build from source if that's how you get Qt, and rebuild your application using it.

Hijacking a five year old thread is not the best way to get attention.