When compiling with g++ -fsanitize=address I get a new-delete-type-mismatch. Is this code wrong? Or is this a Qt Bug?
I found this in a large application and broke it down to the code below. I want to show a QML Item from C++ with QQuickView. But there seems to be a problem in the Destructor of QQuickView.
test.pro:
TEMPLATE = app
TARGET = test
QT += core gui widgets quick
SOURCES += test.cpp
QMAKE_CXXFLAGS += -fsanitize=address
QMAKE_LFLAGS += -fsanitize=address
test.cpp:
#include <QApplication>
#include <QQuickView>
#include <QQuickItem>
int main( int argc, char *argv[] ) {
QApplication app ( argc, argv );
QQuickView view;
view.setSource(QUrl::fromLocalFile("test.qml"));
view.show();
return app.exec();
}
test.qml:
import QtQuick 2.4
Item {
id: item1
anchors.fill: parent
Rectangle {
id: rectangle
color: "#fba4e3"
anchors.fill: parent
}
}
Compile:
$ qmake-qt5 test.pro
$ make
g++ -c -pipe -fsanitize=address -O2 -Wall -W -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtQuick -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtQml -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtCore -I. -isystem /usr/include/libdrm -I/usr/lib64/qt5/mkspecs/linux-g++ -o test.o test.cpp
g++ -fsanitize=address -Wl,-O1 -o test test.o -lQt5Widgets -lQt5Quick -lQt5Gui -lQt5Qml -lQt5Network -lQt5Core -lGL -lpthread
Run:
$ ./test
=================================================================
==6822==ERROR: AddressSanitizer: new-delete-type-mismatch on 0x60f000034de0 in thread T0:
object passed to delete has wrong type:
size of the allocated type: 168 bytes;
size of the deallocated type: 32 bytes.
#0 0x7fc304be16d8 in operator delete(void*, unsigned long) (/lib64/libasan.so.4+0xe16d8)
#1 0x7fc303547e07 in QObjectPrivate::deleteChildren() (/lib64/libQt5Core.so.5+0x27fe07)
#2 0x7fc303548ce1 in QObject::~QObject() (/lib64/libQt5Core.so.5+0x280ce1)
#3 0x7fc304234e44 in QQuickItem::~QQuickItem() (/lib64/libQt5Quick.so.5+0x1ece44)
#4 0x7fc3042501a4 (/lib64/libQt5Quick.so.5+0x2081a4)
#5 0x7fc3042d30f9 in QQuickView::~QQuickView() (/lib64/libQt5Quick.so.5+0x28b0f9)
#6 0x40102d in main (/home/lukas/Programmieren/C++/Qt/test/test+0x40102d)
#7 0x7fc3021a0889 in __libc_start_main (/lib64/libc.so.6+0x20889)
#8 0x401199 in _start (/home/lukas/Programmieren/C++/Qt/test/test+0x401199)
0x60f000034de0 is located 0 bytes inside of 168-byte region [0x60f000034de0,0x60f000034e88)
allocated by thread T0 here:
#0 0x7fc304be0158 in operator new(unsigned long) (/lib64/libasan.so.4+0xe0158)
#1 0x7fc3039ddbf1 in QQmlType::create(QObject**, void**, unsigned long) const (/lib64/libQt5Qml.so.5+0x265bf1)
#2 0x60f00003d2ff (<unknown module>)
SUMMARY: AddressSanitizer: new-delete-type-mismatch (/lib64/libasan.so.4+0xe16d8) in operator delete(void*, unsigned long)
==6822==HINT: if you don't care about these errors you may set ASAN_OPTIONS=new_delete_type_mismatch=0
==6822==ABORTING
This is indeed a known bug in QtQuick that still is not resolved, checkout this bug report.
One of the comments gives some hints about the cause that is apparently related to the fact that the QML engine uses a
new
with a placement destination whose size is bigger than the object that is currently being built. It is probably done for optimization reasons, so no clue if this is ever going to be fixed, but it looks not harmful.