#1996 Floating point exception in gnuplot

[Gwan Yeong Kim]

Hello.

I found a Floating point exception bug in gnuplot.

Please confirm.

Thanks.

OS: Ubuntu 16.04 32bit
Version:gnuplot 5.2 patchlevel 2

% GNUPLOT: LaTeX picture
\setlength{\unitlength}{0.240900pt}
\ifx\plotpoint\undefined\newsavebox{\plotpoint}\fi
\sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
\begin{picture}(1500,900)(0,0)

Program received signal SIGFPE, Arithmetic exception.
0x080af222 in boundary3d (plots=<optimized out>, count=<optimized out>)
    at graph3d.c:408
408     i = (int) (plot_bounds.ytop - plot_bounds.ybot) / t->v_char - 1 - ktitle_lines;
(gdb) bt
#0  0x080af222 in boundary3d (plots=<optimized out>, count=<optimized out>)
    at graph3d.c:408
#1  do_3dplot (plots=<optimized out>, pcount=<optimized out>, 
    quick=<optimized out>) at graph3d.c:716
#2  0x08147e02 in eval_3dplots () at plot3d.c:2368
#3  0x0806f2b5 in splot_command () at command.c:2245
#4  0x08067cdc in command () at command.c:633
#5  do_line () at command.c:423
#6  0x080fd810 in load_file (fp=<optimized out>, name=<optimized out>, 
    calltype=<optimized out>) at misc.c:410
#7  0x0811ebf2 in main (argc=<optimized out>, argv=0xbffff088) at plot.c:654

---

==18104==
==18104== Process terminating with default action of signal 8 (SIGFPE)
==18104== Integer divide by zero at address 0x62E31B7A
==18104== at 0x80AF222: boundary3d (graph3d.c:408)
==18104== by 0x80AF222: do_3dplot (graph3d.c:716)
==18104== by 0x8147E01: eval_3dplots (plot3d.c:2368)
==18104== by 0x806F2B4: splot_command (command.c:2245)
==18104== by 0x8067CDB: command (command.c:633)
==18104== by 0x8067CDB: do_line (command.c:423)
==18104== by 0x80FD80F: load_file (misc.c:410)
==18104== by 0x811EBF1: main (plot.c:654)
==18104==

---

[Ethan Merritt]

Nonsense input from fuzz-testing?
Anyhow, fixed now.

[Gwan Yeong Kim]

Yes.
Thanks for the quick patch.

[Gwan Yeong Kim]

Hello,

I've found a similar issue.

Can you check it out?

Thanks.

==20888== Process terminating with default action of signal 8 (SIGFPE)
==20888==  Integer divide by zero at address 0x10032566A8
==20888==    at 0x4C37C6: boundary3d (graph3d.c:406)
==20888==    by 0x4C37C6: do_3dplot (graph3d.c:717)
==20888==    by 0x5EC4C7: eval_3dplots (plot3d.c:2387)
==20888==    by 0x4430D2: splot_command (command.c:2263)
==20888==    by 0x4348A9: command (command.c:631)
==20888==    by 0x4348A9: do_line (command.c:420)
==20888==    by 0x55C7A7: load_file (misc.c:405)
==20888==    by 0x5996F5: main (plot.c:652)
==20888== 

[Ethan Merritt]

Hmm. I think I may bring this up for discussion on the mailing list.

Your command is interpreted as
set term pslatex [fontsize] 2e60
where the fontsize keyword is implicit for this terminal type.
That's a legal command but obviously the font size is absurdly large and eventually leads to problems. I can fix the specific place in the code that you see a divide by zero but there are probably many other places that will not produce a reasonably calculated value when given an unreasonable input value. There are also many other terminal parameters you could set to an absurd value. Are these bugs or is it a case of "you get what you asked for". Should large numbers be dis-allowed for all scale factors? What is "large"?

The general question is whether or not the program should impose limits on all control values input via the command line. It generally does sanity checks to assure non-zero values where appropriate, but generally does not try to set a maximum positive value.

[Gwan Yeong Kim]

I agree with you.

Perhaps, in general, the user is not executing that command.

I think this problem can be considered in terms of making the software stronger.

Thanks.