Created attachment 11514 [details] PDF that crashes gs The attached file was created by Chromium print-to-file. When I attempted to print it, CUPS failed, reporting that gstoraster failed. (The error message "Directory not empty" was totally misleading.) I eventually traced this down to a crash in gs, as called from gstoraster. However, the crash also occurs if you just run gs on the file without going near CUPS. From with CUPS I snaffled a copy of the file it was passing to gs, as apparently created by pdf2pdf, and it too causes a segfault within gs. Looks like I can only attach one file, however.
Created attachment 11515 [details] PDF data from with CUPS filter that crashes gs
Myself and a colleague have tried both of these files on both Linux and Windows, and are unable to see a problem. Unfortunately you haven't supplied us a command line to work with so we are slightly in the dark. The first thing to do is tell us what command line you are using so we can try that. On the assumption that this will work for us as well, the question then is what version of Linux are you using, and where did you get Ghostscript from ? If its a package of some kind then its likely that Ghostscript has been built to use shared libraries, and my guess would be that one of those libraries is broken/incompatible with Ghostscript. At that point you would need to pull the source from ghostscript.com/downloads and build a copy yourself to try. You probably want to wait until after we've had a try at reproducing the problem first.
Thanks for your quick reply. First, an apology, the file was created by Mozilla, not Chromium. I am running Arch Linux on a 64-bit PC, updated to the latest versions of everything. GhostScript is versioned as 9.15-2. The command I used was just "gs <file name>" in a xterm window. I have already pulled the source of GhostScript and built it myself - I did that when I was trying to figure out what was happening. Running it from within the build (= source) directory, I get this crash: bin/gs ~/tmp/gsbug1.pdf GPL Ghostscript 9.15 (2014-09-22) Copyright (C) 2014 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Segmentation fault (core dumped) I'm happy to try any debugging suggestions you may have. Here is the Arch Linux info for the system's GhostScript. Note that I do have Gutenprint (5.2.10-1) installed. $ pacman -Qi ghostscript Name : ghostscript Version : 9.15-2 Description : An interpreter for the PostScript language Architecture : x86_64 URL : http://www.ghostscript.com/ Licenses : AGPL custom Groups : None Provides : None Depends On : libxt libcups fontconfig jasper zlib libpng>=1.5.7 libjpeg libtiff>=4.0.0 lcms2 dbus libpaper Optional Deps : texlive-core: needed for dvipdf gtk3: needed for gsx [installed] Required By : graphviz gv libspectre Optional For : cups-filters gimp gutenprint imagemagick Conflicts With : None Replaces : None Installed Size : 60.71 MiB Packager : Andreas Radke <andyrtr@archlinux.org> Build Date : Mon Feb 16 19:50:27 2015 Install Date : Mon Mar 2 17:46:45 2015 Install Reason : Explicitly installed Install Script : No Validated By : Signature
(In reply to Philip Hazel from comment #3) > Thanks for your quick reply. First, an apology, the file was created by > Mozilla, not Chromium. I doubt it matters, I can't see anything wrong with the PDF file. > the latest versions of everything. GhostScript is versioned as 9.15-2. OK so that's not a Ghostscript version number, which means that its been packaged, which we can't debug or support. > The > command I used was just "gs <file name>" in a xterm window. Using your file, that works for me and colleague, running different flavours of Linux. So its 'something' to do with your configuration in some way. >I have already > pulled the source of GhostScript and built it myself OK, what did you do to build GS ? specifically did you set any options ? > I'm happy to try any debugging suggestions you may have. Probably the next thing is to do a debug build (make debug) and try the debug version, then if it still seg faults you can run gdb and get us a back trace, which 'might' help. Other than that I'll probably have to get my colleague involved, I'm not a Linux expert. FWIW I doubt this is a problem with the PDF itnerpreter.
I get the same fault with a debug version of GhostScript. I built it just by ./configure; make debug. Running under valgrind shows a bit more detail. A gdb backtrace (see below) gives some more. $ debugbin/gs ~/tmp/gsbug1.pdf GPL Ghostscript 9.15 (2014-09-22) Copyright (C) 2014 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Segmentation fault (core dumped) quercite$ valgrind !! valgrind debugbin/gs ~/tmp/gsbug1.pdf ==17832== Memcheck, a memory error detector ==17832== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17832== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==17832== Command: debugbin/gs /home/ph10/tmp/gsbug1.pdf ==17832== GPL Ghostscript 9.15 (2014-09-22) Copyright (C) 2014 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 ==17832== ==17832== Process terminating with default action of signal 11 (SIGSEGV) ==17832== General Protection Fault ==17832== at 0x6814153: __lll_unlock_elision (in /usr/lib/libpthread-2.21.so) ==17832== by 0x725D34: gp_monitor_leave (gp_psync.c:197) ==17832== by 0x6294C5: gsicc_get_link_profile (gsicc_cache.c:978) ==17832== by 0x628834: gsicc_get_link (gsicc_cache.c:631) ==17832== by 0x61D7A9: gx_remap_ICC (gsicc.c:405) ==17832== by 0xA1FE40: gx_remap_color (gxcmap.c:560) ==17832== by 0x96317E: do_fill (gspaint.c:291) ==17832== by 0x9633AF: fill_with_rule (gspaint.c:345) ==17832== by 0x9633FB: gs_fill (gspaint.c:356) ==17832== by 0x583A05: zfill (zpaint.c:27) ==17832== by 0x534F05: do_call_operator (interp.c:86) ==17832== by 0x53778B: interp (interp.c:1298) ==17832== ==17832== HEAP SUMMARY: ==17832== in use at exit: 19,393,826 bytes in 1,566 blocks ==17832== total heap usage: 3,842 allocs, 2,276 frees, 34,555,046 bytes allocated ==17832== ==17832== LEAK SUMMARY: ==17832== definitely lost: 16 bytes in 1 blocks ==17832== indirectly lost: 176 bytes in 4 blocks ==17832== possibly lost: 0 bytes in 0 blocks ==17832== still reachable: 19,393,634 bytes in 1,561 blocks ==17832== suppressed: 0 bytes in 0 blocks ==17832== Rerun with --leak-check=full to see details of leaked memory ==17832== ==17832== For counts of detected and suppressed errors, rerun with: -v ==17832== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) /home/ph10/bin/valgrind: line 3: 17832 Segmentation fault (core dumped) /usr/bin/valgrind --suppressions=/home/ph10/.valgrind.supp "$@" $ gdb debugbin/gs GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from debugbin/gs...done. (gdb) run ~/tmp/gsbug1.pdf Starting program: /home/source/ghostscript/ghostscript-9.15/debugbin/gs ~/tmp/gsbug1.pdf [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". GPL Ghostscript 9.15 (2014-09-22) Copyright (C) 2014 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 1. Page 1 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6204150 in __lll_unlock_elision () from /usr/lib/libpthread.so.0 (gdb) backtrace #0 0x00007ffff6204150 in __lll_unlock_elision () from /usr/lib/libpthread.so.0 #1 0x0000000000725d35 in gp_monitor_leave (mona=0x1e94148) at ./base/gp_psync.c:197 #2 0x00000000006294c6 in gsicc_get_link_profile (pis=0x1de2aa8, dev=0x1ebd128, gs_input_profile=0x1ea2ae0, gs_output_profile=0x1ea2ae0, rendering_params=0x7fffffffd0f0, memory=0x1db0038, devicegraytok=1) at ./base/gsicc_cache.c:978 #3 0x0000000000628835 in gsicc_get_link (pis=0x1de2aa8, dev_in=0x1ebd128, pcs_in=0x225b958, output_colorspace=0x0, rendering_params=0x7fffffffd0f0, memory=0x1db0038) at ./base/gsicc_cache.c:631 #4 0x000000000061d7aa in gx_remap_ICC (pcc=0x225e120, pcs=0x225b958, pdc=0x225e360, pis=0x1de2aa8, dev=0x1ebd128, select=gs_color_select_texture) at ./base/gsicc.c:405 #5 0x0000000000a1fe41 in gx_remap_color (pgs=0x1de2aa8) at ./base/gxcmap.c:560 #6 0x000000000096317f in do_fill (pgs=0x1de2aa8, rule=-1) at ./base/gspaint.c:291 #7 0x00000000009633b0 in fill_with_rule (pgs=0x1de2aa8, rule=-1) at ./base/gspaint.c:345 #8 0x00000000009633fc in gs_fill (pgs=0x1de2aa8) at ./base/gspaint.c:356 #9 0x0000000000583a06 in zfill (i_ctx_p=0x1dfed00) at ./psi/zpaint.c:27 #10 0x0000000000534f06 in do_call_operator (op_proc=0x5839eb <zfill>, i_ctx_p=0x1dfed00) at ./psi/interp.c:86 #11 0x000000000053778c in interp (pi_ctx_p=0x1dafb10, pref=0x7fffffffdac0, perror_object=0x7fffffffdcc0) at ./psi/interp.c:1298 #12 0x0000000000535721 in gs_call_interp (pi_ctx_p=0x1dafb10, pref=0x7fffffffdbf0, user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/interp.c:510 #13 0x0000000000535550 in gs_interpret (pi_ctx_p=0x1dafb10, pref=0x7fffffffdbf0, user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/interp.c:468 #14 0x00000000005279cb in gs_main_interpret (minst=0x1dafa70, pref=0x7fffffffdbf0, user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/imain.c:247 #15 0x0000000000528930 in gs_main_run_string_end (minst=0x1dafa70, user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/imain.c:660 #16 0x00000000005287fd in gs_main_run_string_with_length (minst=0x1dafa70, str=0x22ae7a0 "<2f686f6d652f706831302f746d702f6773627567312e706466>.runfile", length=60, user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/imain.c:618 #17 0x000000000052876f in gs_main_run_string (minst=0x1dafa70, str=0x22ae7a0 "<2f686f6d652f706831302f746d702f6773627567312e706466>.runfile", user_errors=1, pexit_code=0x7fffffffdcd8, perror_object=0x7fffffffdcc0) at ./psi/imain.c:600 #18 0x000000000052bfcc in run_string (minst=0x1dafa70, str=0x22ae7a0 "<2f686f6d652f706831302f746d702f6773627567312e706466>.runfile", options=3) at ./psi/imainarg.c:988 #19 0x000000000052bf55 in runarg (minst=0x1dafa70, pre=0xac21e3 "", arg=0x7fffffffebe4 "/home/ph10/tmp/gsbug1.pdf", post=0xac239d ".runfile", options=3) at ./psi/imainarg.c:978 #20 0x000000000052bc1e in argproc (minst=0x1dafa70, arg=0x7fffffffebe4 "/home/ph10/tmp/gsbug1.pdf") at ./psi/imainarg.c:902 #21 0x0000000000529eea in gs_main_init_with_args (minst=0x1dafa70, argc=2, argv=0x7fffffffe8e8) at ./psi/imainarg.c:239 #22 0x00000000004613d5 in main (argc=2, argv=0x7fffffffe8e8) at ./psi/gs.c:96
(In reply to Philip Hazel from comment #5) > I get the same fault with a debug version of GhostScript. I built it just by > ./configure; make debug. Running under valgrind shows a bit more detail. A <SNIP> Thanks, that's almost certainly exactly the same problem I'm working on under a different bug (hence marking this as a duplicate). It seems to arisen due to a change in the pthread library behaviour - although the cause is a Ghostscript problem. Give us a few days or so, I should have a fix in place early next week. In the interim, you can get a working build by (after running configure) opening the Makefile, searching for "posync" and replacing that with "nosync". Then run make. *** This bug has been marked as a duplicate of bug 695862 ***
(In reply to Chris Liddell (chrisl) from comment #6) > (In reply to Philip Hazel from comment #5) > > Thanks, that's almost certainly exactly the same problem I'm working on > under a different bug (hence marking this as a duplicate). I did see 695862 and wondered if it was the same, but it wasn't obviously so. > In the interim, you can get a working build by (after running configure) > opening the Makefile, searching for "posync" and replacing that with > "nosync". Then run make. I can confirm that that that does indeed produce a working build. Thank you again for the quick responses. Philip