Bug 167508 - gnuplot - at least x11 display refuses to work
gnuplot - at least x11 display refuses to work
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnuplot (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Phil Knirsch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-03 14:42 EDT by Michal Jaegermann
Modified: 2015-03-04 20:15 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-21 10:42:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a backtrace from a failed attempt to run something in gnuplot (4.83 KB, text/plain)
2005-09-03 14:42 EDT, Michal Jaegermann
no flags Details
Patch to fix bug in gnuplot X11 terminal (456 bytes, patch)
2005-10-15 13:46 EDT, Hans Grobler
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2005-09-03 14:42:16 EDT
Description of problem:

After

  cd /usr/share/doc/gnuplot-4.0.0/demo ; gnuplot all.dem

one gets only

*** buffer overflow detected ***: gnuplot_x11 terminated

and a backtrace.  A sample backtrace from an x86_64 machine is attached but
the same happens on x86 as well.

I did not try to check other possible terminal devices.

Version-Release number of selected component (if applicable):
gnuplot-4.0.0-8

How reproducible:
Always
Comment 1 Michal Jaegermann 2005-09-03 14:42:16 EDT
Created attachment 118424 [details]
a backtrace from a failed attempt to run something in gnuplot
Comment 2 Michal Jaegermann 2005-09-03 14:47:54 EDT
The same runs through 'all.dem' do work on FC3 and FC4 installations but
maybe only due to absent overflow checks?
Comment 3 Gregory Leblanc 2005-10-05 00:11:12 EDT
This is happening to me as well, though I discovered it by way of the octave
frontend.  I had some folks on #fedora verify that this works fine on FC4.  I
can reproduce this when only attempting to plot 3 points, rather than the whole
demo file.
Comment 4 Arjan van de Ven 2005-10-05 13:49:40 EDT
can you install the gnuplot-debuginfo file (has to match the exact version) and
then run it from gdb, make it crash and then type "bt"?
that's supposed to give a lot better backtrace
Comment 5 Michal Jaegermann 2005-10-05 16:21:52 EDT
> that's supposed to give a lot better backtrace ...
Only in this particular case this should be trivially reproducible with
whatever version is currently used in a development.  It looks like
a gnuplot bug caught by checks.  But here we go:

(gdb) bt
#0  0x0000003ca20bc720 in __write_nocancel () from /lib64/libc.so.6
#1  0x0000003ca2067224 in _IO_new_file_write () from /lib64/libc.so.6
#2  0x0000003ca20678c8 in _IO_new_do_write () from /lib64/libc.so.6
#3  0x0000003ca2066ba3 in _IO_new_file_sync () from /lib64/libc.so.6
#4  0x0000003ca205c6b0 in fflush () from /lib64/libc.so.6
#5  0x000000000045c516 in term_end_plot () at term.c:491
#6  0x000000000042578f in do_plot (plots=0x6eec90, pcount=3) at graphics.c:1555
#7  0x000000000043c3d9 in eval_plots () at plot2d.c:1616
#8  0x000000000040b87c in do_line () at command.c:511
#9  0x0000000000432bb2 in load_file (fp=0x6ed400,
    name=0x2a <Address 0x2a out of bounds>, can_do_args=false) at misc.c:267
#10 0x000000000043914c in main (argc=Variable "argc" is not available.
) at plot.c:622
#11 0x0000003ca201cd1f in __libc_start_main () from /lib64/libc.so.6
#12 0x0000000000403989 in _start ()
#13 0x00007fffffe93bb8 in ?? ()
#14 0x0000000000000000 in ?? ()
(gdb) f 5
#5  0x000000000045c516 in term_end_plot () at term.c:491
491             (*term->text) ();
(gdb) list
486         if (!term_initialised)
487             return;
488
489         if (!multiplot) {
490             FPRINTF((stderr, "- calling term->text()\n"));
491             (*term->text) ();
492             term_graphics = FALSE;
493         }
494     #ifdef VMS
495         if (opened_binary)
(gdb)

So the problem is most likely in 'X11_text()' and if functions for various
terminal "devices" follow the same pattern then chances are that the bug
is replicated there as well.

OTOH with a break set on entry to 'X11_text' an exception happens before
that break is hit.  Maybe this 'name' argument to 'load_file()' is realy
messed up and not only a debugger artifact?

Anything which tries to plot something will do to trigger that bug.
Comment 6 Alexandre Oliva 2005-10-11 06:25:58 EDT
FWIW, a command as simple as `plot x' is enough to trigger the bug.
Comment 7 Phil Knirsch 2005-10-11 06:29:07 EDT
OK, will give it a shot today and see where the problem really comes from.

Thanks for the already detailed work, that'll at least give me a really good
starting point.

Read ya, Phil
Comment 8 Hans Grobler 2005-10-15 13:46:15 EDT
Created attachment 120028 [details]
Patch to fix bug in gnuplot X11 terminal

The following patch fixes what appears to be a rather obvious bug. The bug
appears to be present in the gnuplot development branch as well.
Comment 9 Michal Jaegermann 2005-10-15 14:40:31 EDT
Ah, thanks for the patch!

There seems to be another trouble in this 'read_input()' function.  With
this:

        while (rdbuf_offset < total_chars && buf_offset < Nbuf) {
            char c = rdbuf[rdbuf_offset++];
            buf[buf_offset++] = c;
            if (c == '\n')
                break;
        }

we may get, quite legitimately, exactly Nbuf characters but then the next
check will report "buffer overflow in read_input" and quite rightly so
as we are trying to add characters to 'static char buf[Nbuf];'.  The only
saving grace is that we are breaking on '\n' and hardly anyone seem to
have lines of Nbuf size which happens to be defined as 1024.
'buf_offset < Nbuf - 1' would prevent that check to ever trigger.

Do I miss something?
Comment 10 Hans Grobler 2005-10-16 00:52:01 EDT
FYI: The patch I submitted has been added to gnuplot development.

About your comment: I'd say that there is no further problem. 

Reasoning: When buf_offset is at the end of the memory buffer (i.e. when 
buf_offset = Nbuf-2), it will be post-incremented to (Nbuf-1). The loop 
condition will still be true and the next iteration will execute. Since the 
valid buffer offsets are 0 to Nbuf-1, the last byte in the buffer will be 
written (legally). The buf_offset is then effectively incremented to Nbuf (due 
to post-increment). For the next iteration, the loop condition will no longer be 
true and the loop will not be executed. Nowhere in the rest of the function is 
the buffer accessed if buf_offset > (Nbuf-1). If the offset where being pre-
incremented, you would be correct in that there would be another buffer 
offerflow. As is, your modification would not be wrong, but would waste the last 
byte of the buffer.
Comment 11 Michal Jaegermann 2005-10-16 01:17:24 EDT
> Reasoning ....

Well, a quoted loop is terminated when you got '\n', or when rdbuf_offset >=
total_chars or if buf_offset >= Nbuf and the third state does not happen in
practice only because you are likely to hit '\n' somewhere (or run of
characters to stick into the current line).

> Nowhere in the rest of the function is the buffer accessed if 
> buf_offset > (Nbuf-1).

This is correct only because then a guard, which follows, would fire up
and you would get kicked out of the program; quite spuriously, I should add,
because a check in the loop in question should be for 'buf_offset < Nbuf - 1'.
Otherwise you would attempt to put a terminating NUL possibly in a position
'buf_offset = Nbuf'.  What if '\n' was placed at buf[Nbuf - 1]?
Comment 12 Phil Knirsch 2005-10-21 10:42:30 EDT
Fixed in latest FC development build.

Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.