Created attachment 118424 [details]
a backtrace from a failed attempt to run something in gnuplot

The same runs through 'all.dem' do work on FC3 and FC4 installations but
maybe only due to absent overflow checks?

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.

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

> 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.

FWIW, a command as simple as `plot x' is enough to trigger the bug.

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

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.

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?

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.

> 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]?

Fixed in latest FC development build.

Read ya, Phil