Re: [Plplot-devel] ctest failure with Qt file devices

[Hazen B. <hba...@ma...>]

On 11/15/2016 03:36 PM, Alan W. Irwin wrote:
>
>> This is happening with Qt4, specifically:
>
> OK. That very likely means this is our problem and nothing
> to do with Qt4.
>
>> [this] command does not segfault:
>> ./x02c -dev pngqt -o ex2.png
>>
>> But it does segfault in family mode:
>> ./x02c -fam -dev pngqt -o ex2.png
>
> If I recall correctly example 2 moves through the pages in a unique
> but legitimate way that other examples do not use so that may be
> triggering this issue for the qt devices.  So I plan to take a look
> later when I have finished up some other PLplot issues I am currently
> dealing with unless you are able to solve this issue first on your own.
>
> Assuming you do want to investigate further on your own, I would try
> compiling with
>
> export CFLAGS="-g"
> export CXXFLAGS="-g"
>
> (so the valgrind results properly identify code lines and you can
> attach a gdb session (if you like) whenever valgrind finds a memory
> management issue.  Then run valgrind (with --db-attach=yes) on example
> 2 with familying and a variety of qt devices to see if they all have
> memory management issues and exactly what part of our qt code is
> generating those.  My guess is it is something one or all of our qt
> devices does wrong for the end-of-page processing in familying mode
> for the unique way example 2 navigates through its two pages.

Apparently --db-attach has been deprecated. My valgrind results are 
attached, but I'm not sure they tell us that much as (naturally) the 
example does not segfault when run in the context of valgrind.

I also tried running it in gdb, where it did segfault with the following 
backtrace:

(gdb) backtrace
#0  0x00007fffedf1012d in gtk_container_add () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#1  0x00007ffff53095ee in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#2  0x00007ffff530a61e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#3  0x00007ffff530d4be in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#4  0x00007ffff52efe01 in QGtkStyle::QGtkStyle() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5  0x00007ffff5276cbd in QStyleFactory::create(QString const&) () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x00007ffff4f68cce in QApplication::style() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#7  0x00007ffff4f69115 in QApplicationPrivate::initialize() () from 
/usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8  0x00007ffff4f692aa in QApplicationPrivate::construct(_XDisplay*, 
unsigned long, unsigned long) ()
    from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9  0x00007ffff4f69678 in QApplication::QApplication(int&, char**, bool, 
int) ()
    from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x00007ffff5cf1092 in initQtApp (isGUI=true) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:104
#11 0x00007ffff5cf136f in plD_init_rasterqt (pls=0x7ffff7dccee0 <pls0>) 
at /home/hbabcock/Code/plplot/drivers/qt.cpp:279
#12 0x00007ffff7b69de1 in plP_init () at 
/home/hbabcock/Code/plplot/src/plcore.c:144
#13 0x00007ffff7b7b7ce in plGetFam (pls=0x7ffff7dccee0 <pls0>) at 
/home/hbabcock/Code/plplot/src/plctrl.c:2781
#14 0x00007ffff5cf2334 in plD_bop_pngqt (pls=0x7ffff7dccee0 <pls0>) at 
/home/hbabcock/Code/plplot/drivers/qt.cpp:578
#15 0x00007ffff7b6a027 in plP_bop () at 
/home/hbabcock/Code/plplot/src/plcore.c:211
#16 0x00007ffff7b97894 in c_plbop () at 
/home/hbabcock/Code/plplot/src/plpage.c:125
#17 0x0000000000400ed9 in demo2 () at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:70
#18 0x0000000000400e5c in main (argc=1, argv=0x7fffffffdf38) at 
/home/hbabcock/Code/plplot/examples/c/x02c.c:28

One thing that at least looks suspicious is frame #10:
initQtApp (isGUI=true)

Maybe isGUI should be false for the non-interactive devices?

-Hazen