#1184 long tic-label causes crash

[Ben Abbott]

The commands below result in "Abort trap: 6" on MaOS X

set terminal qt enhanced
set xtics in scale 1.4 border mirror ( "-10.0000000, -5.0000000, 0.0000000, 5.0000000, 10.0000000" -10, "-10.0000000, -5.0000000, 0.0000000, 5.0000000, 10.0000000" -5, "-10.0000000, -5.0000000, 0.0000000, 5.0000000, 10.0000000" 0, "-10.0000000, -5.0000000, 0.0000000, 5.0000000, 10.0000000" 5, "-10.0000000, -5.0000000, 0.0000000, 5.0000000, 10.0000000" 10);
plot sin (x)

[Ethan Merritt]

Not nearly enough information here.
OSX version? gnuplot version? qt version?
Did you build from source?
Which process died - gnuplot or gnuplot_qt?
Can you get a traceback or something that would give any hint as to where the error occured.

[Ben Abbott]

backtrace from gdb

[Ben Abbott]

Ethan, I'm able to produce this on both MacOS 10.7.5 with gnuplot 4.6 patch level 1 using "qt" and Ubuntu 12.10 with gnplot 4.6 pathlevel 0 using "wxt".

I've attached the gdb backtrace from Ubuntu.

[Ethan Merritt]

This is a really depressing bug.
Depressing because it damages my evaluation of the quality of the original gnuplot code base.

It turns out that the underlying problem is in gprintf(). This function was added to gnuplot back in the mists of time (between version 3.5 and 3.7, prior to the SourceForge code repositoty). At the time of its introduction, the API for gprintf() included a parameter limiting the number of characters transferred to the output string. This is as it should be. And gnuplot contributors have been good about passing correct limits when strings in gnuplot are formatted using gprintf.

BUT NO ONE EVER IMPLEMENTED THE LENGTH PROTECTION IN gprintf()?!
The "count" parameter is silently ignored, and always has been, without so much as a FIXME or warning comment. What crap.

So I guess it's me off to re-write or at least thoroughly audit gprintf().

The only bright side of this is that the higher level code is actually pretty robust, and in that sense the failure you are seeing is a false alarm produced by building with the gcc-specific compiler option -fstack-protector. If you build gnuplot without that compiler flag there is no error, and no program failure. The program correctly warns about over-long tic labels and does not corrupt the stack. So the compiler flag is useful in that it does detect a real error, but not the one it purports to test for.

Anyhow, I have confirmed that
1) the error you report is reproducible if the -fstack-protector compiler
flag is used
2) the problem is triggered by passing a string constant to gprintf()
with strlen(format) > MAX_ID_LEN
3) this problem has been present in the code since it was first
placed on SourceForge (1999; version 3.7)
4) A quick fix imposing the requested limit on the length of the
string formatted by gprintf does not exhibit the Abort from the
-fstack-protector code.

[Ethan Merritt]

CVS for 4.7 now contains a complete fix. The gprintf() code now uses snprintf and safe_strncpy throughout.

CVS for 4.6 will need a less rigorous fix unless we decide to start requiring snprintf support (it's not required in 4.6.1).