PDA

View Full Version : QGraphicsLinearLayout::~QGraphicsLinearLayout() - crash on clean up



mrcz
19th July 2011, 00:10
Hello,

while developing in qt i came across following problem (Several hours of googling gave me no answer or hint of cause):

During shutdown of the application, it crashes while deleting instance of QGraphicsLinearLayout (A sample application which can reproduce the issue is in attachment).

Valgrind output launching the binary and then attempting to close the window:


==13872== Memcheck, a memory error detector
==13872== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==13872== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==13872== Command: ./graphicstest
==13872==
==13872== Invalid read of size 4
==13872== at 0x482F852: QGraphicsWidget::~QGraphicsWidget() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x560B0C7: ???
==13872== Address 0x560b590 is 0 bytes inside a block of size 8 free'd
==13872== at 0x4026B2C: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==13872== by 0x47E94B9: QGraphicsLinearLayout::~QGraphicsLinearLayout() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x4E86232: (below main) (in /lib/libc-2.14.so)
==13872==
==13872== Invalid write of size 4
==13872== at 0x47E8EEF: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8FB1: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x560B0C7: ???
==13872== Address 0x560b590 is 0 bytes inside a block of size 8 free'd
==13872== at 0x4026B2C: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==13872== by 0x47E94B9: QGraphicsLinearLayout::~QGraphicsLinearLayout() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x4E86232: (below main) (in /lib/libc-2.14.so)
==13872==
==13872== Invalid read of size 4
==13872== at 0x47E8E94: QGraphicsLayoutItem::parentLayoutItem() const (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8EF9: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8FB1: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x560B0C7: ???
==13872== Address 0x560b594 is 4 bytes inside a block of size 8 free'd
==13872== at 0x4026B2C: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==13872== by 0x47E94B9: QGraphicsLinearLayout::~QGraphicsLinearLayout() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x4E86232: (below main) (in /lib/libc-2.14.so)
==13872==
==13872== Invalid read of size 4
==13872== at 0x47E8E97: QGraphicsLayoutItem::parentLayoutItem() const (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8EF9: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8FB1: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x560B0C7: ???
==13872== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==13872==
==13872==
==13872== Process terminating with default action of signal 11 (SIGSEGV)
==13872== Access not within mapped region at address 0x8
==13872== at 0x47E8E97: QGraphicsLayoutItem::parentLayoutItem() const (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8EF9: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x47E8FB1: QGraphicsLayoutItem::~QGraphicsLayoutItem() (in /usr/lib/libQtGui.so.4.7.3)
==13872== by 0x560B0C7: ???
==13872== If you believe this happened as a result of a stack
==13872== overflow in your program's main thread (unlikely but
==13872== possible), you can try to increase the size of the
==13872== main thread stack using the --main-stacksize= flag.
==13872== The main thread stack size used in this run was 8388608.
==13872==
==13872== HEAP SUMMARY:
==13872== in use at exit: 659,939 bytes in 3,442 blocks
==13872== total heap usage: 31,396 allocs, 27,954 frees, 4,724,184 bytes allocated
==13872==
==13872== LEAK SUMMARY:
==13872== definitely lost: 216 bytes in 1 blocks
==13872== indirectly lost: 0 bytes in 0 blocks
==13872== possibly lost: 98,000 bytes in 1,058 blocks
==13872== still reachable: 561,723 bytes in 2,383 blocks
==13872== suppressed: 0 bytes in 0 blocks
==13872== Rerun with --leak-check=full to see details of leaked memory
==13872==
==13872== For counts of detected and suppressed errors, rerun with: -v
==13872== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 77 from 12)
Segmentation fault


Any suggestions? I don't presume it's qt bug, perhaps i'm doing some mistake i am unaware of.

Library and application versions:
qt: 4.7.3-3
qtcreator: 2.2.1-3
valgrind: 3.6.1-2

Thanks in advance for any reply.

mcosta
19th July 2011, 09:13
can you post the code?

mrcz
19th July 2011, 10:21
it is in attachment as a qtcreator project, but i certainly can:

main.cpp


#include <QtGui/QApplication>
#include <QGraphicsScene>
#include <QGraphicsView>

#include "widget.h"

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

QGraphicsScene scene;
widget w;
scene.addItem(&w);

QGraphicsView view;
view.setScene(&scene);
view.show();

return app.exec();
}


widget.h


#ifndef WIDGET_H
#define WIDGET_H

#include <QGraphicsWidget>
#include <QGraphicsLinearLayout>

class widget : public QGraphicsWidget {
Q_OBJECT
public:
explicit widget(QGraphicsWidget *parent = 0) : QGraphicsWidget(parent) {
w = new QGraphicsWidget();
l = new QGraphicsLinearLayout();
l->addItem(w);
this->setLayout(l);
}
~widget() {
if (w != NULL) {
delete w;
w = NULL;
}
if (l != NULL) {
delete l;
l = NULL;
}
}
protected:
QGraphicsWidget* w;
QGraphicsLinearLayout* l;
};
#endif


Thank you for a reply.

mcosta
19th July 2011, 10:55
I think the problem is the "widget" destructor

You have not delete widget children, Qt delete them when necessary

sakya
19th July 2011, 11:16
I tried to just comment the line

this->setLayout(l);
and the crash is gone. Maybe the layout is deleted before the destructor?

mrcz
19th July 2011, 11:23
that's what i always assumed as standart procedure - destructors are called implicitly when the application exits, thus the children get deleted there, however i applied following modification to demonstrate there is clearly no difference:


main.cpp

#include <QApplication>
#include <QGraphicsScene>
#include <QGraphicsView>

#include "widget.h"

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

QGraphicsScene scene;
widget w;
scene.addItem(&w);

QGraphicsView view;
view.setScene(&scene);
view.show();

QObject::connect(&app, SIGNAL(aboutToQuit()), &w,
SLOT(deleteChildren()));
return app.exec();
}


widget.h


#ifndef WIDGET_H
#define WIDGET_H

#include <QGraphicsWidget>
#include <QGraphicsLinearLayout>

class widget : public QGraphicsWidget {
Q_OBJECT
public:
explicit widget(QGraphicsWidget *parent = 0) : QGraphicsWidget(parent) {
w = new QGraphicsWidget();
l = new QGraphicsLinearLayout();
l->addItem(w);
this->setLayout(l);
}

~widget() {
QObject::disconnect(this, SLOT(deleteChildren()));
if (w != NULL) {
delete w;
w = NULL;
}
if (l != NULL) {
delete l;
l = NULL;
}
}

public slots:
void deleteChildren() {
if (w != NULL) {
delete w;
w = NULL;
}
if (l != NULL) {
delete l;
l = NULL;
}
}
protected:
QGraphicsWidget* w;
QGraphicsLinearLayout* l;
};
#endif // WIDGET_H


now the children get deleted when application emits signal. The result is however same - deletion of the QGraphicsLinearLayout produces crash with same valgrind output.

Thanks for suggestion though.

sakya: but uhm... then the widget doesn't have it's inner layout applied... you might be right however... by setting the layout, QGraphicsWidget manages it itself. So fix might be either setting layout to none before exit, or not deleting it explicitly myself.

Going to try it, thanks.

MarekR22
19th July 2011, 11:38
READ DOCUMENTATION:
http://doc.qt.nokia.com/latest/qgraphicswidget.html#layout-prop :

QGraphicsWidget (http://doc.qt.nokia.com/latest/qgraphicswidget.html) takes ownership of layout.

http://doc.qt.nokia.com/latest/qgraphicslinearlayout.html#details :

the layout takes ownership of the items.
So you don't have to delete anything!

sakya
19th July 2011, 11:49
So you don't have to delete anything!
I knew that, but isn't strange that the program doesn't crash when deleting w (child of l)?
W should have been deleted as a child of the layout, no?

mrcz
19th July 2011, 11:52
perhaps there is another check performed while in case of layout isn't?

thanks for pointing out the documentation ... seems i missed that fact.