On Wed, Mar 11, 2015 at 08:24:17PM +0000, Andrew Ross wrote: > On Tue, Mar 10, 2015 at 06:36:42PM -0700, Alan Irwin wrote: > > 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. > > > > 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. > > I'm also stumped! I'll try building in my Debian unstable pbuilder > environment and report back. This is as close as I can get and should > (hopefully) help isolate the problem.
A minimal C / C++ / qt5 build of plplot on debian unstable produces the output below. No invalid reads though. I suspect the DRM warnings are because I'm building in a chrooted pbuilder environment. So unless the problem lies in the DRM support, it looks like the issue is not present in debian unstable with 5.3.2 (the current package is 5.3.2+dfsg-4+b1). Andrew root@andrew-laptop:~/software/plplot/build_sid# valgrind examples/c/x01c -dev qtwidget ==14430== Memcheck, a memory error detector ==14430== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14430== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==14430== Command: examples/c/x01c -dev qtwidget ==14430== PLplot library version: 5.10.0 libGL error: failed to open drm device: No such file or directory libGL error: failed to load driver: i965 libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast process 14430: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory See the manual page for dbus-uuidgen to correct this issue. ==14438== Warning: invalid file descriptor 1024 in syscall close() ==14438== Warning: invalid file descriptor 1025 in syscall close() ==14438== Warning: invalid file descriptor 1026 in syscall close() ==14438== Warning: invalid file descriptor 1027 in syscall close() ==14438== Use --log-fd=<number> to select an alternative log fd. ==14438== Warning: invalid file descriptor 1028 in syscall close() ==14438== Warning: invalid file descriptor 1029 in syscall close() ==14438== ==14438== HEAP SUMMARY: ==14438== in use at exit: 371,780 bytes in 3,118 blocks ==14438== total heap usage: 8,976 allocs, 5,858 frees, 1,241,797 bytes allocated ==14438== ==14438== LEAK SUMMARY: ==14438== definitely lost: 2,476 bytes in 10 blocks ==14438== indirectly lost: 24 bytes in 1 blocks ==14438== possibly lost: 4,676 bytes in 83 blocks ==14438== still reachable: 364,604 bytes in 3,024 blocks ==14438== suppressed: 0 bytes in 0 blocks ==14438== Rerun with --leak-check=full to see details of leaked memory ==14438== ==14438== For counts of detected and suppressed errors, rerun with: -v ==14438== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==14430== ==14430== HEAP SUMMARY: ==14430== in use at exit: 198,976 bytes in 3,013 blocks ==14430== total heap usage: 31,133 allocs, 28,120 frees, 7,033,974 bytes allocated ==14430== ==14430== LEAK SUMMARY: ==14430== definitely lost: 3,064 bytes in 41 blocks ==14430== indirectly lost: 129,797 bytes in 2,420 blocks ==14430== possibly lost: 4,676 bytes in 83 blocks ==14430== still reachable: 61,439 bytes in 469 blocks ==14430== suppressed: 0 bytes in 0 blocks ==14430== Rerun with --leak-check=full to see details of leaked memory ==14430== ==14430== For counts of detected and suppressed errors, rerun with: -v ==14430== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) ------------------------------------------------------------------------------ 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
