Re: strange multiplot behavior with wxt

[Allin C. <cot...@wf...>]

On Wed, 28 Jun 2023, Ethan A Merritt wrote:

> On Wednesday, 28 June 2023 05:50:15 PDT Allin Cottrell wrote:
>> I'm puzzled by a multiplot example where the output seems to be
>> non-deterministic -- though the fault may be in my script
>> (strange_multi.plt, attached).
>>
>> I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using
>> the wxt terminal for screen display with the command line
>>
>> gnuplot strange_multi.plt -persist
>
> I have kept source and executables around for many versions of gnuplot.
> I can reproduce your "missing bars in first plot" symptom with old
> executables for 5.4.0 through 5.4.6, but not with 5.4.8 or the
> development branch.  Any given executable seems to be 100% reproducible
> in either failing or succeeding.
>
> But here's the thing - if I rebuild 5.4.3 from the same original
> source, I get a new executable that does not exhibit the problem.
> So my suspicion is that the difference is the version of the
> wx- shared libraries the binary is linked against.
>
> old gnuplot_5.4.3 binary (built May 2022)
> [~/temp] ldd /usr/local/bin/gnuplot_5.4.3 | grep wx
>        libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007fc634b09000)
>        libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007fc634a25000)
>        libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007fc6349f6000)
>        libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007fc634000000)
>        libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007fc6349e2000)
>        libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007fc63497f000)
>        libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007fc633c00000)
>
> new gnuplot_5.4.3 binary (built today)
> [~/temp] ldd ~/cvs/gnuplot-5.4.3/src/gnuplot | grep wx
>        libwx_gtk3u_xrc-3.2.so.0 => /lib64/libwx_gtk3u_xrc-3.2.so.0 (0x00007f3cedc64000)
>        libwx_gtk3u_html-3.2.so.0 => /lib64/libwx_gtk3u_html-3.2.so.0 (0x00007f3cedb83000)
>        libwx_gtk3u_qa-3.2.so.0 => /lib64/libwx_gtk3u_qa-3.2.so.0 (0x00007f3cedb54000)
>        libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f3ced200000)
>        libwx_baseu_xml-3.2.so.0 => /lib64/libwx_baseu_xml-3.2.so.0 (0x00007f3cedb42000)
>        libwx_baseu_net-3.2.so.0 => /lib64/libwx_baseu_net-3.2.so.0 (0x00007f3cedade000)
>        libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f3cece00000)
>
> But it's only a suspicion. [...]

I have a little more information to contribute. I'm testing my 
example on two machines. The one I'm sitting at runs Fedora 36,
with gnuplot 5.4.3 and wx 3.0.5 (per wx-config). The linkage is

myrtle:~$ ldd /usr/bin/gnuplot | grep wx
         libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fa5bfc00000)
         libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fa5bf800000)

On this machine I'm seeing the non-deterministic behavior.

The other machine I'm accessing remotely via ssh. It runs current 
Arch Linux with gnuplot 5.4.8 and wx 3.2.2, linkage:

robroy:~$ ldd /usr/bin/gnuplot | grep wx
         libwx_gtk3u_core-3.2.so.0 => /usr/lib/libwx_gtk3u_core-3.2.so.0 (0x00007f5447a00000)
         libwx_baseu-3.2.so.0 => /usr/lib/libwx_baseu-3.2.so.0 (0x00007f5447600000)

On this more up-to-date system I now think I was wrong to say the 
behavior is non-deterministic. The plot appears somewhat slowly over 
the remote connection, and here's the reproducible sequence I'm 
seeing over 2 or 3 seconds:

* an empty (black) window appears
* the canvas goes to white
* the first subplot appears, correctly
* the second subplot appears, correctly
* the data portion of the first subplot is wiped out to white

Might this help with diagnosis?

Allin Cottrell