#1894 corruption of input script from stdin

[Thomas Orgis]

This is with gnuplot 5.0.5 or CVS of today, the attached script with the attached data results in correct plot, but makes gnuplot print out spurious error messages about the input script that look like something got messed up (repeated bits stitched together):

gnuplot < badplot.plot

gnuplot> plot 'badplot.dat' with ls
                                   ^
         line 0: unrecognized plot type

gnuplot> et output
         ^
         line 0: invalid command

It seems not to happen every time, but close. It vanishes when using
another terminal than x11 (e.g. dumb or png). I am not sure about other
graphical terminals. The wxt of the CVS build didn't run because of
C++ ABI mismatch ... sorry, my time is limited and I got a deadline
on a scientific paper.

I hope this is reasonably easy to identify for someone who knows their
way around the gnuplot codebase.

[Thomas Orgis]

Forgot to mention: This does not happen when giving the script as argument to gnuplot. Also, it seems that it (sometimes?) works the first time around and then consistenly produces the error (while still plotting correctly). Perhaps there indeed is some interaction with Xorg. The platform is a custom GNU/Linux on x86-64 with Xorg-server 1.18.3 and fluxbox 1.3.7.

And you indeed need the provided data. Producing more trivial data did not trigger the bug.

[Ethan Merritt]

I can't reproduce the problem here, but based on your description I predict that a possible work-around is to add the command "unset mouse" immediately before the command "set term x11". If you can produce the plots you need without mousing that may be sufficient for your immediate need.

Is your gnuplot executable linked against libreadline? libedit? If you are not sure, please show the output from "show version long".

[Thomas Orgis]

Ah, the picture is getting clearer. Or more murky, depending on your mood.

So far I was not able to reproduce it with unset mouse. But I also was unable to reproduce it when I did not have a maximised gnuplot window already present. Thing is this: I have fluxbox configured to group gnuplot windows together, sharing one geometry. When I got the existing window maximised, I have a chance to see the new plot window appearing with small geometry and
being resized to fit the group geometry … and then a chance to see the bogus script error messages.

There seems to be a timing element involved. I guess that is why I needed the more complex data: There needs to be a certain number of drawing elements so that gnuplot spends time drawing things, redrawing things on resize.

My gnuplot is linked against libreadline, but not libedit. Built using gcc-6.3.0 and glibc-2.24. And I can apparenlty continue to work just fine, as the issue is so far purely cosmetic, regarding the dirty console output suggesting to me that I (or my scripts) made errors. The plots themselves seem to be fine. I only have a rather uneasy feeling about the memory corruption …

[Ethan Merritt]

There is no memory corruption. What happens is that if you are piping input to gnuplot (e.g. when the program is invoked as "gnuplot < inputstream") and mousing at the same time, then the input layer has to multiplux the two input sources and figure out which input characters are from the mouse and which are from stdin. If the terminal-specifc mouse code finds that it has by mistake received a character from the input command stream, it tries to stuff the character back at the head of the input queue. This stuff-back-onto-the-queue operation is not 100% guaranteed to work, so sometimes the main input stream either loses a character or gains an unexpected character. The opportunity for this kind of failure arises mostly when a mouse operation takes longer than expected (where "mouse operation" really means any event notification from the plot window). The most common cause is slow font initialization, but as you say it's all a matter of timing. The consequence of this failure mode is usually that the input stream command containing the missing or extra character is not recognized and therefore is not executed. That's why you see an error message. But that wouldn't normally prevent subsequent commands in the input stream from executing successfully [1].

It is also possible that the error is being triggered not by an expected mouse event that is running late, but by an event that was not expected at all. Maybe the automated resize event that you described? I could imagine that fluxbox sends event notifications that don't exactly match those from window managers that more people are running. Perhaps we just need to teach gnuplot's x11 terminal "if you see an event labeled XYZ just ignore it, don't try to process it as input of any sort". If you really want to track this down I think it would require enabling debug statements in the x11 terminal code to log events as they are seen.

---

[1] Hypothetically a perfect storm of bad events might result in a dirrerent sort of error; e.g. the misplaced character might occur in an awkward place like "set output 'ilename.outf'" which would produce no error message but an incorrectly named output file. I don't think anyone has ever reported this.

[Ethan Merritt]

I think this is a duplicate of #2208, which is now fixed.