#1336 Abort trap on using {\Symbol} in pdf enhanced terminal

[Anonymous]

After update to Mac OSX 10.9.1, the {\Symbol} command causes an abort trap 6

Test gnuplot file:
set terminal pdf enhanced dashed
set xlabel 'X [{/Symbol m} m]'
plot sin(x)
set output

Error message:
/sw/bin/gnuplot: line 6: 78901 Abort trap: 6 /sw/bin/gnuplotx "$@"

Gnuplot version 4.6.4, install through fink.

Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64

[Ethan Merritt]

That error message does not provide any hint about where the error occurred. I don't think anyone can help you without having a more complete trace of the error.

That said, I really doubt this is a gnuplot bug. Here, for example, is a report of a similar problem using Symbol font with Xfig:
https://sourceforge.net/p/fink/mailman/message/31741985/
And here may be a parallel case for a different font
http://tex.stackexchange.com/questions/140840/lualatex-luaotfload-broke-after-upgrading-to-mavericks

[Alexander Wittig]

I can confirm this error on several OS X machines with gnuplot built from MacPorts.

gnuplot 4.6 patchlevel 5
MacPorts 2.3.1
Mac OS X 10.9.4
Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64

I do not think it is related to the bugs mentioned above, as this happens for any font (not just Symbol, also Times or Helvetica). Plus, if the same font is set in the terminal settings, everything works.
Note that the crash can be reproduced by just running the gnuplot demo script for enhanced output.

The only error output is an "Abort" on the screen, a gdb stack trace shows this:

Program received signal SIGABRT, Aborted.
0x00007fff8bb37866 in __pthread_kill ()
(gdb) bt
#0  0x00007fff8bb37866 in __pthread_kill ()
#1  0x00007fff82f6835c in pthread_kill ()
#2  0x00007fff81661b1a in abort ()
#3  0x00007fff81661c91 in abort_report_np ()
#4  0x00007fff81685860 in __chk_fail ()
#5  0x00007fff81685870 in __chk_fail_overlap ()
#6  0x00007fff816858a1 in __chk_overlap ()
#7  0x00007fff816859f4 in __strncpy_chk ()
#8  0x00000001000aa0d0 in PDF_set_font ()
#9  0x00000001000aabea in ENHPDF_FLUSH ()
#10 0x000000010008e349 in enhanced_recursion ()
#11 0x00000001000ca87f in ENHPDF_put_text ()
#12 0x000000010008a6d7 in write_multiline ()
#13 0x0000000100030021 in do_plot ()
#14 0x000000010005cc1d in eval_plots ()
#15 0x000000010000f483 in do_line ()
#16 0x000000010004a578 in load_file ()
#17 0x00000001000551cf in main ()

I think this is rather due to this:
http://postgresql.1045698.n5.nabble.com/OSX-doesn-t-accept-identical-source-target-for-strcpy-anymore-td5776101.html

Strictly speaking, OS X is standard compliant (albeit rather strict) as the C99 standard ISO/IEC 9899:1999 states in §7.21.2.3 on strcpy(): "If copying takes place between objects that overlap, the behavior is undefined."

Maybe additional checks can be added to PDF_set_font to prevent strcpy on overlapping (presumably identical) strings?

[Ethan Merritt]

Thank you for that trace.

I had assumed that the original report referred to the cairo library pdf terminal driver, but I see from your trace that it comes from the PDFLib driver instead. Does MacPorts really provide a gnuplot executable linked against a proprietary library? (yeah I know there's a PDFLib Lite version, but it still has a non-free license that forbids commercial use).

FWIW tracing execution of this script on linux using valgrind does detect an overlap for gnuplot version 4.6.5 but not for gnuplot 5 (rc2). So backporting a pair of trivial code changes to pdf.trm may fix this, but I am inclined to say that the long-term fix for this is "don't use PDFLib".

That terminal driver (pdf.trm) has not received much attention since the introduction of cairo support (cairo.trm). Given that you can get good PDF output from gnuplot via either the cairo or qt libraries or via lua/tikz, the rationale for continued support of PDFLib is pretty weak.

[Alexander Wittig]

Thanks for the quick response and fix in v5! I just compiled the 5rc2 tarball and can confirm that the problem is fixed on my system.

I agree, the pdfcairo driver is the way to go. Seeing how it supports unicode it also makes the \Symbol font unnecessary in most cases. My only problem with it is that it produces significantly larger PDF files (in one particular case with 100.000s of points over several plots the size is almost three times that of the old pdf driver, 4 MB vs. 11 MB). I never tried the qt or lua/tikz drivers (seems a bit overkill to have a full qt just for PDF output).

You're right, the default MacPorts gnuplot doesn't come with PDFlib bindings. But they still have a port for PDFlib lite and a gnuplot variant one can enable to build with the old PDF driver.