gnuplot-beta

strange multiplot behavior with wxt

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

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

On some invocations the frequency bars appear in the first sub-plot, 
on other invocations they do not appear, the upper plot shows no 
data. But if I write the plot to file using, say, pngcairo or 
pdfcairo, the first sub-plot is always OK.

Am I misusing multiplot or might there be a bug here?

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: strange multiplot behavior with wxt

[Ethan A M. <me...@uw...>]

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.  It could instead be a difference in some
other set of libraries, or in the compiler version used.  Or it could be
a timing issue that either is or is not triggered by generated code.
Perhaps the generated code for your semi-reproducible case hits right
on the edge of that timing. 
In any case I don't think the difference indicates a change in the gnuplot
source code.

Having said all that, if someone pins down the actual point of failure
or timing issue, perhaps we could code around it.   

	Ethan

> On some invocations the frequency bars appear in the first sub-plot, 
> on other invocations they do not appear, the upper plot shows no 
> data. But if I write the plot to file using, say, pngcairo or 
> pdfcairo, the first sub-plot is always OK.
> 
> Am I misusing multiplot or might there be a bug here?
> 
> 

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

Re: strange multiplot behavior with wxt

[Ethan A M. <me...@uw...>]

Valgrind finds a test of an uninitialized flag "hidden" that could
plausibly be involved here.
I have corrected that by setting the flag to FALSE in the one place
that I could see initialization omitted, but I do not actually
understand why that code path is triggered by this test case (it is
the response to a "refresh" command).  That makes valgrind happy, so
maybe it will fix your display also.  I'll leave the tracker issue
"open" for now.


On Wed, Jun 28, 2023 at 10:31 AM Allin Cottrell <cot...@wf...> wrote:
>
> 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



-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: strange multiplot behavior with wxt

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

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

> Valgrind finds a test of an uninitialized flag "hidden" that could
> plausibly be involved here.
> I have corrected that by setting the flag to FALSE in the one place
> that I could see initialization omitted, but I do not actually
> understand why that code path is triggered by this test case (it is
> the response to a "refresh" command).  That makes valgrind happy, so
> maybe it will fix your display also.  I'll leave the tracker issue
> "open" for now.

Thanks, Ethan! I've built gnuplot 6.1.0 from gnuplot-main git and 
tested on Fedora: it works fine. I'll also try on Arch with more 
recent wx, but it looks like you've nailed the problem.

Just wondering: are you likely to cherry-pick this fix into 
branch-5-4-stable?

Allin Cottrell

>
> On Wed, Jun 28, 2023 at 10:31 AM Allin Cottrell <cot...@wf...> wrote:
>>
>> 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

Re: strange multiplot behavior with wxt

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

On Thu, 29 Jun 2023, Allin Cottrell wrote:

> On Wed, 28 Jun 2023, Ethan A Merritt wrote:
>
>> Valgrind finds a test of an uninitialized flag "hidden" that could
>> plausibly be involved here.
>> I have corrected that by setting the flag to FALSE in the one place
>> that I could see initialization omitted, but I do not actually
>> understand why that code path is triggered by this test case (it is
>> the response to a "refresh" command).  That makes valgrind happy, so
>> maybe it will fix your display also.  I'll leave the tracker issue
>> "open" for now.
>
> Thanks, Ethan! I've built gnuplot 6.1.0 from gnuplot-main git and tested on 
> Fedora: it works fine. I'll also try on Arch with more recent wx, but it 
> looks like you've nailed the problem.

I can confirm that the fix also works for wx 3.2.2.

Allin Cottrell