| Summary: | QSvgWidget produce segfaults : x11-libs/qt-svg | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | antonmx <antonmx> |
| Component: | [OLD] Library | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | jaak, mlohse, realnc, rossi.f, sakharov, yrusinov |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugreports.qt.nokia.com/browse/QTBUG-6774 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
updated ebuild
patch for the src/svg/qsvgwidget.cpp patch for the src/svg/qsvgwidget.h test application segfaulting with broken Qt lib cave info qt-gui qt-svg-4.7.1.ebuild patch against qt-svg-4.7.1 |
||
|
Description
antonmx
2010-01-19 02:54:27 UTC
Created attachment 216864 [details]
updated ebuild
Created attachment 216865 [details, diff]
patch for the src/svg/qsvgwidget.cpp
Created attachment 216866 [details, diff]
patch for the src/svg/qsvgwidget.h
I don't see how this bug is specific to Gentoo... please explain. Upstream doesn't seem to have applied it on qt-svg module so we need to add this on qt-svg-4.6.1 as well (In reply to comment #4) > I don't see how this bug is specific to Gentoo... please explain. > The bug was reproduced only on Gentoo (5 times, see the original report at qt.nokia.com). No confirmations on other platforms. Of cause it does not mean it is Gentoo-specific, but look like it is. Upstream closed the bug report as "not a Qt bug". However I can consistently reproduce the crash with Qt 4.6.1, using the following reduced testcase:
#include <QApplication>
#include <QSvgWidget>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QSvgWidget();
return 0;
}
Is this still reproducible with 4.6.2? I am not confident with applying the attached patches since upstream rejected them (In reply to comment #8) > Is this still reproducible with 4.6.2? Yes. (In reply to comment #8) > Is this still reproducible with 4.6.2? I am not confident with applying the > attached patches since upstream rejected them > Yes. I just keep applying the same patch to each next version. I can confirm this on my system:
* glib-2.22.4
* glibc-2.11-r1
* qt-4.6.2
* gcc-4.4.3
* gentoo-sources-2.6.31-r5
Recompiling glib, glibc, qt didn't show any effect.
The patch is a nice workaround for the segfault, however this is just the tip of the ice-berg. Even for a simple dummy application like this...
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
return 0;
}
...valgrind reveals a whole bunch of invalid reads/writes and unfreed memory errors. Actually I'm surprised that most Qt/KDE applications get away with it without crashing.
I don't have any such issues on my Kubuntu box in the office (same version of Qt but probably different versions for gcc, glibc,... - I need to check tomorrow). So either this is a Gentoo-specific problem or a problem with another library or the kernel.
ping, need to get this fixed ( by applying the patches, since upstream doesn't cooperate ), or push it for discussion in our next meeting Created attachment 230997 [details]
test application segfaulting with broken Qt lib
how to build:
$ qmake -project svgtest.cpp
$ echo QT += svg >> svgtest.pro
$ make
$ ./svgtest
This crashes with a broken Qt lib (Gentoo default), but works fine with custom build Qt lib (both 4.6.2)
There must be something wrong with the modular way we build Qt on Gentoo. I took the Qt source from the distfiles directory, extracted and build it manually. Result: The above mentioned test application works just fine with the custom build but crashes with the Gentoo build (on the same machine, same build environment, etc...) I recommend to push it to the meeting. Perhaps someone comes up with a clean solution or has an idea where to start looking. PS: A friend of mine also reproduced this bug on his amd64. (In reply to comment #12) > ping, need to get this fixed ( by applying the patches, since upstream doesn't > cooperate ), or push it for discussion in our next meeting > I think we should discuss this issue at the next Qt meeting and try to find the root cause. Upstream rejected the patches so we shouldn't apply them. I did some tests and it seems the bug is related to our qt modularization. I tried it on exherbo too but it works(both amd64, same gcc, glibc, cxxflags/ldflags, qt etc...; the same svgtest compiled on gentoo works fine in exherbo). Pay attention it has a monolithic qt. I kindly asked the sourcemagery guys about that bug and they can't reproduce it(sourcemagery has monolithic qt too). wired verified that this is caused by our modular qt-svg ebuild. We'll try to find the root cause. If the investigation won't be successful, qt-svg will be merged into qt-gui, controlled by a new 'svg' USE flag. This solution is not so bad as the final solution, the real problem is... there are a lot of packages that will need a rewrite in the tree. The push has to be done(ideally) at the same time as the packages updates... and probably for most of them (maybe we can avoid the ones which have only a blocker with qt-svg as they have already a block with qt-gui) it will need a revision bump. Let's hope to find the root cause(hopefully with the doable fix), but this bug is becoming more and more voodo stuff and I'm a bit discouraged about it. Need to make this a top priority for our next meeting. I would propose to gather up and try to figure what to in a separate session if needed. http://tinderbox.dev.gentoo.org/misc/rindex/x11-libs/qt-svg There are so many packages that depend on qt-svg so merging it with qt-gui should be the very last solution I would proposed to start building Qt with gdb symbols support so we can look deeper on that http://www.gentoo.org/proj/en/qa/backtraces.xml Unfortunately I can't reproduce the crash when I run the test case under valgrind :-( Yes, it doesn't crash in valgrind - yet you should see several invalid read/write errors. However, running it in a debugger gives me this (received SIGABRT): 0 __kernel_vsyscall 0 0xb7fdf424 1 raise /lib/libc.so.6 0 0xb6d99f71 2 abort /lib/libc.so.6 0 0xb6d9b7b9 3 ?? /lib/libc.so.6 0 0xb6dd71a5 4 ?? /lib/libc.so.6 0 0xb6ddd86f 5 ?? /lib/libc.so.6 0 0xb6de08ac 6 malloc /lib/libc.so.6 0 0xb6de276c 7 qMalloc(unsigned int) /usr/lib/qt4/libQtCore.so.4 0 0xb718c2bb 8 QHashData::allocateNode(int) /usr/lib/qt4/libQtCore.so.4 0 0xb71b32e3 9 QWidgetPrivate::init(QWidget*, QFlags<Qt::WindowType>) /usr/lib/qt4/libQtGui.so.4 0 0xb755548b 10 QWidget::QWidget(QWidgetPrivate&, QWidget*, QFlags<Qt::WindowType>) /usr/lib/qt4/libQtGui.so.4 0 0xb7555757 11 QSvgWidget::QSvgWidget(QWidget*) /usr/lib/qt4/libQtSvg.so.4 0 0xb7ea5aab 12 main 0 0x080488a8 I grepped for QT_NO_SVG in those files as this bug is obviously triggered by a configuration setting - but nothing :( I'm going to rebuild Qt with debug symbols this weekend... perhaps I find something then. WTF... you get the abort during object construction/allocation, while for me it's exactly the opposite: glibc complains about a double free and gdb shows a stack trace full of destructors... Hmm, yeah weird... I used to get a segmentation fault when reparenting the SvgWidget to any other Widget (either in the constructor or by calling setParent() later - doesn't matter). But now I even get the SIGABRT with the test application mentioned in #7 which worked fine for me a few weeks ago. (In reply to comment #7) > Upstream closed the bug report as "not a Qt bug". However I can consistently > reproduce the crash with Qt 4.6.1, using the following reduced testcase: > > #include <QApplication> > #include <QSvgWidget> > > int main(int argc, char *argv[]) > { > QApplication app(argc, argv); > QSvgWidget(); > return 0; > } > Something is really weird also because the Makefile generated by qmake is not considering QSvg stuff (missing include path and lib). An exec which segfaults is created by setting manually the -I and -l parameters to INCPATH and LIBS respectively. (In reply to comment #24) > (In reply to comment #7) > > Upstream closed the bug report as "not a Qt bug". However I can consistently > > reproduce the crash with Qt 4.6.1, using the following reduced testcase: > > > > #include <QApplication> > > #include <QSvgWidget> > > > > int main(int argc, char *argv[]) > > { > > QApplication app(argc, argv); > > QSvgWidget(); > > return 0; > > } > > > > Something is really weird also because the Makefile generated by qmake is not > considering QSvg stuff (missing include path and lib). An exec which segfaults > is created by setting manually the -I and -l parameters to INCPATH and LIBS > respectively. > Did you put 'QT += svg' inside the .pro file? (In reply to comment #25) > Did you put 'QT += svg' inside the .pro file? Oops, my fault. I didn't know about that... The same with x11-libs/qt-svg-4.6.3 on my box. Any solutions yet? I can't reproduce any longer with qt 4.7.1, but valgrind still reports 1 invalid read and 2 invalid writes involving QSvgWidgetPrivate. ==7234== Invalid write of size 8 ==7234== at 0x52862A2: QWidgetPrivate::QWidgetPrivate(int) (qwidget.cpp:277) ==7234== by 0x4E6BB19: QSvgWidget::QSvgWidget(QWidget*) (qsvgwidget.cpp:83) ==7234== by 0x4009A2: main (in /tmp/svgcrash) ==7234== Address 0xe7c9350 is 0 bytes after a block of size 496 alloc'd ==7234== at 0x4C26B8E: operator new(unsigned long) (vg_replace_malloc.c:261) ==7234== by 0x4E6BB09: QSvgWidget::QSvgWidget(QWidget*) (qsvgwidget.cpp:93) ==7234== by 0x4009A2: main (in /tmp/svgcrash) ==7234== ==7234== Invalid read of size 4 ==7234== at 0x52E78C8: QX11Info::~QX11Info() (qx11info_x11.cpp:104) ==7234== by 0x52889CA: QWidgetPrivate::~QWidgetPrivate() (qwidget.cpp:323) ==7234== by 0x4E6BD02: QSvgWidgetPrivate::~QSvgWidgetPrivate() (qsvgwidget.cpp:83) ==7234== by 0x5E9DA2B: QObject::~QObject() (qscopedpointer.h:62) ==7234== by 0x52965B9: QWidget::~QWidget() (qwidget.cpp:1620) ==7234== by 0x4009AE: main (in /tmp/svgcrash) ==7234== Address 0xe7c95f0 is 0 bytes inside a block of size 16 free'd ==7234== at 0x4C2535F: operator delete(void*) (vg_replace_malloc.c:387) ==7234== by 0x5E9631E: QObjectPrivate::deleteChildren() (qobject.cpp:1949) ==7234== by 0x52964FA: QWidget::~QWidget() (qwidget.cpp:1600) ==7234== by 0x4009AE: main (in /tmp/svgcrash) ==7234== ==7234== Invalid write of size 4 ==7234== at 0x52E78CC: QX11Info::~QX11Info() (qx11info_x11.cpp:104) ==7234== by 0x52889CA: QWidgetPrivate::~QWidgetPrivate() (qwidget.cpp:323) ==7234== by 0x4E6BD02: QSvgWidgetPrivate::~QSvgWidgetPrivate() (qsvgwidget.cpp:83) ==7234== by 0x5E9DA2B: QObject::~QObject() (qscopedpointer.h:62) ==7234== by 0x52965B9: QWidget::~QWidget() (qwidget.cpp:1620) ==7234== by 0x4009AE: main (in /tmp/svgcrash) ==7234== Address 0xe7c95f0 is 0 bytes inside a block of size 16 free'd ==7234== at 0x4C2535F: operator delete(void*) (vg_replace_malloc.c:387) ==7234== by 0x5E9631E: QObjectPrivate::deleteChildren() (qobject.cpp:1949) ==7234== by 0x52964FA: QWidget::~QWidget() (qwidget.cpp:1600) ==7234== by 0x4009AE: main (in /tmp/svgcrash) ==7234== Created attachment 255423 [details]
cave info qt-gui
Are you sure?
I'm on qt-4.7.1 too, but the bug is still present.
Can you paste some infos about your box ? I will put mine on attachment...
I think that qt-svg also needs qt-gui[accessibility=] because of QWidgetPrivate.
My qt-gui was built with USE="accessibility", and hence I also got this bug. After modifying the qt-svg ebuild to use the same accessibility setting as qt-gui, things appear to work fine. So in the ebuild:
-IUSE="iconv"
+IUSE="accessibility iconv"
-DEPEND="~x11-libs/qt-gui-${PV}[aqua=,debug=]"
+DEPEND="~x11-libs/qt-gui-${PV}[accessibility=,aqua=,debug=]"
and substitute "-no-accessibility" with "$(qt_use accessibility)" in the "myconf" variable.
Created attachment 257027 [details]
qt-svg-4.7.1.ebuild
Created attachment 259512 [details, diff]
patch against qt-svg-4.7.1
Adds accessibility USE flag and removes a couple of redundant configure options from ${myconf}.
patch in tree, thank you all for your contributions (In reply to comment #33) > patch in tree, thank you all for your contributions You need "+accessibility" in IUSE to be consistent with the other qt ebuils. |
