Created attachment 10950 [details] x.eps This command line often (but not always) crashes due to glibc 'fortify' checks: gs -sDEVICE=png16m -sOutputFile=/dev/null -dSAFER -dPARANOIDSAFER -dNOPAUSE -q x.eps Error: /syntaxerror in -file- Operand stack: pageheader Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1902 1 3 %oparray_pop 1901 1 3 %oparray_pop --nostringval-- 1885 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1175/1684(ro)(G)-- --dict:0/20(G)-- --dict:113/200(L)-- Current allocation mode is local GPL Ghostscript 9.14: Unrecoverable error, exit code 1 *** Error in `gs': corrupted double-linked list: 0x0000000002545a20 *** ======= Backtrace: ========= /lib64/libc.so.6[0x338f075cff] /lib64/libc.so.6[0x338f07bb27] /lib64/libc.so.6[0x338f07d083] /lib64/libgs.so.9(+0x3ce450)[0x7f8acf1bc450] /lib64/libgs.so.9(+0x3ca375)[0x7f8acf1b8375] /lib64/libgs.so.9(gs_notify_all+0x28)[0x7f8acf1a9fb8] /lib64/libgs.so.9(gs_font_finalize+0x22)[0x7f8acf19d092] /lib64/libgs.so.9(+0x1bdcfa)[0x7f8acefabcfa] /lib64/libgs.so.9(alloc_restore_step_in+0x68)[0x7f8acefad058] /lib64/libgs.so.9(alloc_restore_all+0x47)[0x7f8acefad207] /lib64/libgs.so.9(gs_main_finit+0x21f)[0x7f8acef681bf] /lib64/libgs.so.9(gsapi_exit+0x13)[0x7f8acef6c0b3] gs(main+0xaf)[0x400a9f] /lib64/libc.so.6(__libc_start_main+0xf5)[0x338f021d65] gs[0x400b0d] Valgrind also has complaints, e.g.: ==3386== Conditional jump or move depends on uninitialised value(s) ==3386== at 0x4DF3701: refs_clear_marks (igcref.c:118) ==3386== by 0x4DF192D: gc_objects_clear_marks.isra.0 (igc.c:622) ==3386== by 0x4DF22BF: gs_gc_reclaim (igc.c:266) ==3386== by 0x4E7274B: context_reclaim (zcontext.c:291) ==3386== by 0x4DBF886: ireclaim (ireclaim.c:155) ==3386== by 0x4DBB422: interp_reclaim (interp.c:441) ==3386== by 0x4DB20C3: gs_main_finit (imain.c:883) ==3386== by 0x4DB60B2: gsapi_exit (iapi.c:537) ==3386== by 0x400A9E: main (dxmainc.c:90) and ==3386== Invalid write of size 4 ==3386== at 0x4DF4282: refs_compact (igcref.c:760) ==3386== by 0x4DF31B7: gs_gc_reclaim (igc.c:1350) ==3386== by 0x4E7274B: context_reclaim (zcontext.c:291) ==3386== by 0x4DBF886: ireclaim (ireclaim.c:155) ==3386== by 0x4DBB422: interp_reclaim (interp.c:441) ==3386== by 0x4DB20C3: gs_main_finit (imain.c:883) ==3386== by 0x4DB60B2: gsapi_exit (iapi.c:537) ==3386== by 0x400A9E: main (dxmainc.c:90) ==3386== Address 0x70ee308 is 16 bytes after a block of size 131,192 alloc'd ==3386== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3386== by 0x4FEFC05: gs_heap_alloc_bytes (gsmalloc.c:183) etc
Unsurprisingly, I can't reproduce this - given the nature of the problem, without replicating the exact environment and build (libraries versions, build options, etc.), it's unlikely to manifest in the same way. And given that this is memory corruption, "Word Size" is a pretty vital piece of information to include. I do see a bunch of valgrind issues, which I will investigate, but note that valgrind is *very* prone to false positives in the garbage collector code. Valgrind appears to struggle with unions and bit fields, and the gc code makes *extensive* use of both of those constructs. I've investigates a significant number of valgrind issues in the garbage collector, and all but two have been erroneous.
This is on x86_64.
I just reproduced this from: tar jxf ghostscript-9.14.tar.bz2 cd ghostscript-9.14 ./configure make GS_LIB=Resource/Init bin/gs -sDEVICE=png16m -sOutputFile=/dev/null -dSAFER -dPARANOIDSAFER -dNOPAUSE -q ../x.eps I'm using Fedora 20 x86_64, fully updated. $ ldd bin/gs linux-vdso.so.1 => (0x00007fff8fd20000) libXt.so.6 => /lib64/libXt.so.6 (0x0000003d19600000) libSM.so.6 => /lib64/libSM.so.6 (0x0000003d16400000) libICE.so.6 => /lib64/libICE.so.6 (0x0000003398c00000) libXext.so.6 => /lib64/libXext.so.6 (0x0000003394000000) libX11.so.6 => /lib64/libX11.so.6 (0x0000003392800000) libcupsimage.so.2 => /lib64/libcupsimage.so.2 (0x0000003204200000) libcups.so.2 => /lib64/libcups.so.2 (0x0000003208400000) libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003d15000000) libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003d15400000) libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003d14c00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x000000339a000000) libpthread.so.0 => /lib64/libpthread.so.0 (0x000000338f800000) libm.so.6 => /lib64/libm.so.6 (0x000000338f400000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003205a00000) libz.so.1 => /lib64/libz.so.1 (0x0000003390000000) libdl.so.2 => /lib64/libdl.so.2 (0x000000338fc00000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x0000003be0c00000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x0000003be0800000) libc.so.6 => /lib64/libc.so.6 (0x000000338f000000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003d14800000) libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003392c00000) libssl.so.10 => /lib64/libssl.so.10 (0x0000003d16000000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003ed0400000) libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00000033ae800000) libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00000033ae000000) libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003d15800000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003fb4600000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003391c00000) /lib64/ld-linux-x86-64.so.2 (0x000000338ec00000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003206200000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003394c00000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f9fd1d9c000) libXau.so.6 => /lib64/libXau.so.6 (0x0000003393000000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x0000003395000000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003ecf400000) librt.so.1 => /lib64/librt.so.1 (0x0000003390800000) libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003d18600000) liblzma.so.5 => /lib64/liblzma.so.5 (0x0000003ecf000000) Those belong to: avahi-libs-0.6.31-21.fc20.x86_64 cups-libs-1.7.2-2.fc20.x86_64 dbus-libs-1.6.12-8.fc20.x86_64 expat-2.1.0-7.fc20.x86_64 fontconfig-2.11.0-1.fc20.x86_64 freetype-2.5.0-5.fc20.x86_64 glibc-2.18-12.fc20.x86_64 keyutils-libs-1.5.9-1.fc20.x86_64 krb5-libs-1.11.5-5.fc20.x86_64 libcom_err-1.42.8-3.fc20.x86_64 libICE-1.0.8-6.fc20.x86_64 libpng-1.6.6-3.fc20.x86_64 libselinux-2.2.1-6.fc20.x86_64 libSM-1.2.1-6.fc20.x86_64 libuuid-2.24.2-1.fc20.x86_64 libX11-1.6.1-1.fc20.x86_64 libXau-1.0.8-2.fc20.x86_64 libxcb-1.9.1-3.fc20.x86_64 libXext-1.3.2-2.fc20.x86_64 libXt-1.1.4-7.fc20.x86_64 nss-softokn-freebl-3.16.1-1.fc20.x86_64 openssl-libs-1.0.1e-37.fc20.1.x86_64 pcre-8.33-4.fc20.x86_64 xz-libs-5.1.2-8alpha.fc20.x86_64 zlib-1.2.8-3.fc20.x86_64
Thanks, I'll see what I can do - it will be a week or two before I can get to it.
I *believe" this commit solves the problem: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=4994e176c4 *But* I have been unable to reproduce exactly the problem you're seeing (it resolves all the valgrind issues I observed). If you could give this patch a whirl and see if it also resolves the fortify error, I'll leave the bug open for a while.
Thanks, yes, that fixes it.
Thanks for the confirmation.