#1614 arrow pointing towards a corner of the canvas

[Anonymous]

Kubuntu 15.04
Gnuplot Version 4.6 patchlevel 6 last modified September 2014
Build System: Linux x86_64

very weird bug:

set terminal png size 640,480
set output "test.png"
set size square
set xrange[-10:10]
set yrange [-10:10]
set xlabel "sth"
set ylabel "sth"
set title "something"
set arrow  from 0,0 to 34.3, 24.3
plot sin(x)

should give me line pointing towards upper-right corner, but instead it points toward lower-left

it seems it matters that the line is pointing (almost) exactly to the corner of the canvas

[Ethan Merritt]

I can't reproduce this using 4.6.6 on linux 86_64 (not Kubuntu). The only thing that comes to mind is to check what version of libgd is installed.

[Karl Ratzsch]

The official 4.6.6 64 bit windows build (zip file from sf.net, uses libgd-2-733361a31aab.dll) reproduces the problem, so does 4.6.4 (32 bit) with the old bgd.dll version of libgd. 5.0.0 is not affected.

[Karl Ratzsch]

On my linux box (xubuntu 15.04) with libgd 2.1.0, all gnuplot versions (4.6.6, 5.0rc2 from backports, 5.0-cvs) create the arrow in the bottom left quadrant.

5.0rc2, in difference to the others, gives an arrowhead at (0,0).

[Ethan Merritt]

Pretty sure that nothing has changed in gnuplot's gd terminal driver for a looong time, other than adding minimal dashedtype handling in version 5. The problem being described smells like integer overflow or signed/unsigned confusion. Less likely is some flakiness that depends on compiler optimization level.

Anyhow, I can't reproduce it here with either libgd 2.1.0 or 2.0.36 so I don't think I can help much.

[Tatsuro MATSUOKA]

Windows bainaries that procuded by Bastain (4.6.4, 5.0.0(32bit) 5.0.2(testing 32bit)) give expected results but binaries prepared by me give results as you were shown. Bastain and I use different build system. Perhaps the difference gave the different resluts but I do not have enough information on this matter.

[gbm]

Attached patch fixes the problem for me. The problem appears in all low resolution terminals (here is 'png' with 640,480 pixels).

[Tatsuro MATSUOKA]

I can confirm the patch fixes the issue on my MinGW64(Windows).

[Ethan Merritt]

OK. I'll apply it. But I would be more confident that it is a true fix if you managed to trap an integer overflow in the specific problem case. I just can't see anywhere in the code where this could happen. And I still can't reproduce the problem on any of my machines. Not for png and not for other bitmap terminal types.

[gbm]

Sorry.
I should have been more explicit in describing the problem and its fix.
It is not an integer overflow bug.
It is a problem of implicit float to integer casting/conversion.
The problematic arrow in the bug sample script intercepts
the clip area bottom at (1.314,0.), the clip area top at (678.44,479),
the clip area left at (0.,-0.929), and the clip area right at (639,451.096).

When x and y are declared as integer, the left intersection (0.,-0.929)
is converted (for some compilers settings) to (0,0) making it
a false positive intersection in line 377 of 'gadgets.c'.
The bottom intersection is converted (1,0), different from (0,0).
Thus, lines 391 to 394 do not consider them the same intersection.

The bug is solved when the implicit integer conversion is moved
to inside the 'if (...' statements in lines 365, 370, 379, and 384.
This is exactly what the bugfix does.