On 2015-03-03 17:09-0800 Alan W. Irwin wrote:
> I think valgrind would report a serious issue like invalid read
> regardless of command-line options so I think the best summary of the
> situation is valgrind reports invalid reads with epa_built Qt 5.3.1
> and 5.3.2 and does not report such issues with Ubuntu-built (and
> patched) Qt5 5.3.0.
>
> So thanks to your report my working hypothesis now is that the
> configuration of the epa_built Qt5 is somehow to blame here even
> though there are no warnings about the configuration options that I
> use in the Qt5 build log.
>
> My next step is I am going to download the Qt5 build configuration
> used by Debian testing and/or Ubuntu to see if I can spot some key
> configuration option that epa_build is missing for Qt5.3.x.
Hi Andrew:
The short story is that step did not work.
Here is the longer version of the story with a request for two
additional tests (one short one long) by you at the end.
There are only three differences between my latest epa_build
configuration (commit cfc6e13) and the Debian (testing) one.
# Do not build the examples and tests.
-nomake examples
-nomake tests
# There is no system harfbuzz for Debian stable so disable (the
# default if harfbuzz is not mentioned).
#-system-harfbuzz
# Do not optimize the build (since I want a fast build)
-no-optimized-qmake
Since the epa_build of qt5 now includes virtually every component, the
build now takes two hours (!) rather than 20 minutes on Linux. But
valgrind still reports an invalid read error when I exit from -dev
qtwidget, although now there are some additional strange invalid file
descriptor warnings from valgrind that I get first which I have never
seen before.
wine@raven> valgrind examples/c/x01c -dev qtwidget
==8241== Memcheck, a memory error detector
==8241== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8241== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8241== Command: examples/c/x01c -dev qtwidget
==8241==
PLplot library version: 5.10.0
==8247== Warning: invalid file descriptor 1024 in syscall close()
==8247== Warning: invalid file descriptor 1025 in syscall close()
==8247== Warning: invalid file descriptor 1026 in syscall close()
==8247== Use --log-fd=<number> to select an alternative log fd.
==8247== Warning: invalid file descriptor 1027 in syscall close()
==8247== Warning: invalid file descriptor 1028 in syscall close()
==8241== Invalid read of size 8
==8241== at 0xE7EDBE4: QXcbShmImage::destroy() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0xE7EDC1B: QXcbBackingStore::~QXcbBackingStore() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0xE7EDC58: QXcbBackingStore::~QXcbBackingStore() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0x76E2672: QBackingStore::~QBackingStore() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Gui.so.5.3.2)
==8241== by 0x81A10E1: QWidgetPrivate::deleteTLSysExtra() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x81A271F: QWidget::destroy(bool, bool) (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x818AB62: QWidget::~QWidget() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x7DF64B8: QtPLWidget::~QtPLWidget() (in
/home/wine/newstart/build_script/install-linux/lib/libplplotqt.so.1.0.0)
==8241== by 0x7039875: plD_tidy_qtwidget(PLStream*) (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/drivers/qt.so)
==8241== by 0x4E509FE: c_plend1 (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/src/libplplot.so.12.0.1)
==8241== by 0x4E50A62: c_plend (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/src/libplplot.so.12.0.1)
==8241== by 0x40158B: main (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/examples/c/x01c)
==8241== Address 0x1482ea78 is 40 bytes inside a block of size 48 free'd
==8241== at 0x4C27D4E: free (vg_replace_malloc.c:427)
==8241== by 0xE7EDB97: QXcbShmImage::destroy() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0xE7EDC1B: QXcbBackingStore::~QXcbBackingStore() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0xE7EDC58: QXcbBackingStore::~QXcbBackingStore() (in
/home/wine/newstart/build_script/install-linux/plugins/platforms/libqxcb.so)
==8241== by 0x76E2672: QBackingStore::~QBackingStore() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Gui.so.5.3.2)
==8241== by 0x81A10E1: QWidgetPrivate::deleteTLSysExtra() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x81A271F: QWidget::destroy(bool, bool) (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x818AB62: QWidget::~QWidget() (in
/home/wine/newstart/build_script/install-linux/lib/libQt5Widgets.so.5.3.2)
==8241== by 0x7DF64B8: QtPLWidget::~QtPLWidget() (in
/home/wine/newstart/build_script/install-linux/lib/libplplotqt.so.1.0.0)
==8241== by 0x7039875: plD_tidy_qtwidget(PLStream*) (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/drivers/qt.so)
==8241== by 0x4E509FE: c_plend1 (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/src/libplplot.so.12.0.1)
==8241== by 0x4E50A62: c_plend (in
/home/wine/newstart/build_script/build_dir-linux/epa_build/Build/build_plplot/src/libplplot.so.12.0.1)
==8241==
==8241==
==8241== HEAP SUMMARY:
==8241== in use at exit: 221,665 bytes in 2,287 blocks
==8241== total heap usage: 68,441 allocs, 66,154 frees, 15,809,667 bytes
allocated
==8241==
==8241== LEAK SUMMARY:
==8241== definitely lost: 2,390 bytes in 35 blocks
==8241== indirectly lost: 65,068 bytes in 1,392 blocks
==8241== possibly lost: 4,676 bytes in 83 blocks
==8241== still reachable: 149,531 bytes in 777 blocks
==8241== suppressed: 0 bytes in 0 blocks
==8241== Rerun with --leak-check=full to see details of leaked memory
==8241==
==8241== For counts of detected and suppressed errors, rerun with: -v
==8241== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 20 from 9)
The differences between these results and your corresponding relatively
clean valgrind results on Ubuntu can be explained a number of ways.
(1) Upstream Qt 5.3.0 (which I believe is the version you are testing on
Ubuntu) does not
have this problem while later upstream Qt5 versions do.
(2) The ubuntu packages are built with a different Qt5 build configuration than
Debian's packages.
(3) One of the above differences from the Debian build configuration
options for Qt5 is causing the issue.
(4) The Debian (and possibly Ubuntu) patches are essential here, and
the issue is caused by the epa_build of an unpatched version of Qt5.3.2.
(5) Some (Debian stable) system library that Qt5 depends on generates
a memory management issue when it closes. Here is the list of the
possibilities (with the "grep -v home" pipeline stanza removing the epa_built
libraries).
wine@raven> ldd drivers/qt.so |& grep -v home
linux-vdso.so.1 => (0x00007fff8d1af000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fbe3aa20000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbe3a79e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fbe3a588000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbe3a1fc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fbe39fe0000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbe39dc9000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007fbe39b68000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0
(0x00007fbe39941000)
libEGL.so.1 => /usr/lib/x86_64-linux-gnu/libEGL.so.1
(0x00007fbe39722000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7
(0x00007fbe39518000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6
(0x00007fbe38280000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
(0x00007fbe37f45000)
libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48
(0x00007fbe37d76000)
libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48
(0x00007fbe37c05000)
libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48
(0x00007fbe36a94000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbe3688f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbe36486000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbe3cef3000)
libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0
(0x00007fbe36260000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x00007fbe3605e000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x00007fbe35e57000)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1
(0x00007fbe35c56000)
libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0
(0x00007fbe35a3e000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
(0x00007fbe3581e000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1
(0x00007fbe35617000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2
(0x00007fbe3540b000)
libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0
(0x00007fbe35205000)
libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0
(0x00007fbe34ffe000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
(0x00007fbe34df4000)
libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0
(0x00007fbe34bf0000)
libudev.so.0 => /lib/x86_64-linux-gnu/libudev.so.0 (0x00007fbe349e0000)
libwayland-client.so.0 => /usr/lib/libwayland-client.so.0
(0x00007fbe347d7000)
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0
(0x00007fbe345ca000)
libgbm.so.1 => /usr/lib/x86_64-linux-gnu/libgbm.so.1
(0x00007fbe343c5000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
(0x00007fbe33d5b000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007fbe33b55000)
libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5
(0x00007fbe33948000)
I view the first 4 of these possibilities as extremely unlikely, but I am
grasping at straws here! I think (1) is unlikely since an upstream
regression in memory management for Qt5 surely would have been
detected by someone else. I think (2) and (3) are unlikely since I
have gone through an extremely wide range of build configuration
options for Qt5 (I must have gone through something like 10 of these
builds in the last three days). Regardless of changes I have tried, I
always get the same result; good Qt5 configuration, build, and install
results and a single invalid read issue reported by valgrind on exit
from -dev qtwidget. I think (4) is unlikely because I have looked at
the 8 patches in qtbase-opensource-src-5.3.2+dfsg/debian/patches/ and
most have to do with exotic architecture support for Debian, and none
of them have to do with a memory management bug fix.
That leaves (5) as the best working hypothesis right now in my
opinion. After all, from the above valgrind message, the invalid read
is caused by something done by plend/plend1/plD_tidy_qtwidget. I
don't completely understand the C++ part of that (plD_tidy_qtwidget).
I assume it closes the Qt5 libraries which in turn close the system
libraries which would mean there is a lot of scope there for a
bad/clumsy/invalid library closing for just one of the system
libraries which is listed above.
If you have access to Debian testing, it would be great if you
repeated the valgrind test with their binary version of Qt5 (5.3.2)
which is very much closer to my epa_built version. And if you have a
spare couple of hours of cpu on a Debian testing platform, it would
also be extremely interesting to see if the epa_built version of Qt5
did not have any memory management issues on Debian testing since if
that proved to be the case I could write this off to Debian stable
issues (i.e., the current working hypothesis) and sleep better at
night. :-)
Meanwhile, if you can think of anything else I should try with the
epa_built version of Qt5 on Debian stable, please let me know.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
