Bug 695862 - Segmentation fault when converting from PDF to JPG, machine dependant
Summary: Segmentation fault when converting from PDF to JPG, machine dependant
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: 9.15
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
: 695868 695881 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-03-10 09:16 UTC by Karl
Modified: 2015-03-23 03:09 UTC (History)
5 users (show)

See Also:
Customer:
Word Size: ---


Attachments
Test file to reproduce seg fault on some machines. (39.25 KB, application/pdf)
2015-03-10 09:16 UTC, Karl
Details
gdb log with thread apply all backtrace full (14.27 KB, text/plain)
2015-03-11 02:52 UTC, Karl
Details
PDF file causing segmentation fault (39.02 KB, application/pdf)
2015-03-11 17:45 UTC, Michael Weiner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl 2015-03-10 09:16:55 UTC
Created attachment 11503 [details]
Test file to reproduce seg fault on some machines.

I have setup two headless servers, different in hardware.

I install my Linux distribution on them and ghostscript 9.15. 

On one machine, the conversion from PDF to JPG works with the attached sample, on the other not.

I have compiled from scratch, used binary provided by Ghostscript, reinstalled both machines from scratch, compared installed libs, but I can't solve this. 

I have noted that adding "-dNOTRANSPARENCY" allows me to convert the file on the erroring machine, but this is not a solution.

It would be great if you could look into this and I would be happy to provide more information on your request.

Server 1 (working):
# gs -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.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

Server 2 (not working):
# gs -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.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
Comment 1 Marcos H. Woehrmann 2015-03-10 12:27:23 UTC
I've tried reproducing this on the half dozen or so linux machines I have access to and can't get it to fail.  I've also running with valgrind but it reports no issues.

Could you try building the debug version and seeing if that fails?  If it does a gdb stack trace would be very helpful.
Comment 2 Karl 2015-03-11 01:36:54 UTC
Here is the info from GDB

# gdb gs
GNU gdb (GDB; openSUSE 13.2) 7.8
Copyright (C) 2014 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-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
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"...

warning: /etc/gdbinit.d/gdb-heap.py: No such file or directory
Reading symbols from gs...Reading symbols from /usr/lib/debug/usr/bin/gs.debug...done.
done.
(gdb) run -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.pdf'
Starting program: /usr/bin/gs -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.pdf'
Got object file from memory but can't read symbols: File truncated.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/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.
__lll_unlock_elision (lock=lock@entry=0x17166b8, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
29      ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory.
(gdb)
Comment 3 jsmeix 2015-03-11 02:28:25 UTC
Only FYI a non-helpful info (because I noticed "openSUSE 13.2"):
I cannot reproduce it on my openSUSE 13.2 system:
----------------------------------------------------------------------------
# gs -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 \
 -sOutputFile='test.jpg' 'test.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

# echo $?
0
----------------------------------------------------------------------------

bugzilla@dubistmeinheld.de,
I think Marcos H. Woehrmann requested a GDB backtrace
i.e. the output of the 'bt' command in GDB directly
after the segmentation fault, cf.
ftp://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_42.html
for example you can do it as as described at
https://en.opensuse.org/openSUSE:Bugreport_application_crashed

FYI: elision-unlock.c belongs to glibc but when a segfault happens
in a glibc function the usual root cause is not in that clibc function
but at some level above wherefrom that clibc function was called in
a wrong way (e.g. with a pointer that points to an invaild address).
A GDB backtrace shows all that levels above which helps to find
out what called that glibc function in a wrong way.
Comment 4 Karl 2015-03-11 02:50:13 UTC
Thank you for pointing me to the right direction and the explanation. 

Here is the gdb with bt:
# gdb gs                                                                                                                                      
GNU gdb (GDB; openSUSE 13.2) 7.8                                                                                                                                        
Copyright (C) 2014 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-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
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"...

warning: /etc/gdbinit.d/gdb-heap.py: No such file or directory
Reading symbols from gs...Reading symbols from /usr/lib/debug/usr/bin/gs.debug...done.
done.
(gdb) run -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.pdf'
Starting program: /usr/bin/gs -dBATCH -dNOPAUSE -sDEVICE=jpeg -dJPEGQ=85 -sOutputFile='test.jpg' 'test.pdf'
Got object file from memory but can't read symbols: File truncated.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/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.
__lll_unlock_elision (lock=lock@entry=0x17166b8, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
29      ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or directory.
(gdb) bt
#0  __lll_unlock_elision (lock=lock@entry=0x17166b8, private=0) at ../nptl/sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
#1  0x00007ffff701653d in __pthread_mutex_unlock_usercnt (mutex=mutex@entry=0x17166b8, decr=decr@entry=1) at pthread_mutex_unlock.c:66
#2  0x00007ffff70165ca in __GI___pthread_mutex_unlock (mutex=mutex@entry=0x17166b8) at pthread_mutex_unlock.c:310
#3  0x00000000006561f9 in gp_monitor_leave (mona=0x17166b8) at base/gp_psync.c:197
#4  0x00000000005ac949 in gsicc_get_link_profile (pis=pis@entry=0x1643958, dev=dev@entry=0x1ac8898, gs_input_profile=gs_input_profile@entry=0x1723eb0, 
    gs_output_profile=0x1723eb0, rendering_params=rendering_params@entry=0x7fffffffce40, memory=<optimized out>, devicegraytok=1) at base/gsicc_cache.c:978
#5  0x00000000005acf5e in gsicc_get_link (pis=pis@entry=0x1643958, dev_in=dev_in@entry=0x1ac8898, pcs_in=pcs_in@entry=0x1c777e8, 
    output_colorspace=output_colorspace@entry=0x0, rendering_params=rendering_params@entry=0x7fffffffce40, memory=<optimized out>) at base/gsicc_cache.c:631
#6  0x00000000005a70ea in gx_remap_ICC (pcc=0x1c7b3f0, pcs=0x1c777e8, pdc=0x1c7b630, pis=0x1643958, dev=0x1ac8898, select=gs_color_select_texture) at base/gsicc.c:405
#7  0x000000000085d598 in gx_remap_color (pgs=0x1643958) at base/gxcmap.c:560
#8  0x00000000007e1490 in do_fill (rule=1, pgs=0x1643958) at base/gspaint.c:291
#9  fill_with_rule (pgs=0x1643958, rule=1) at base/gspaint.c:345
#10 0x00000000004fec85 in interp (pi_ctx_p=pi_ctx_p@entry=0x160d190, pref=<optimized out>, perror_object=perror_object@entry=0x7fffffffd950) at psi/interp.c:1298
#11 0x00000000004ffa79 in gs_call_interp (perror_object=0x7fffffffd950, pexit_code=0x7fffffffd94c, user_errors=1, pref=0x7fffffffd7f0, pi_ctx_p=0x160d230)
    at psi/interp.c:510
#12 gs_interpret (pi_ctx_p=pi_ctx_p@entry=0x160d190, pref=pref@entry=0x7fffffffd920, user_errors=1, user_errors@entry=-9904, pexit_code=0x7fffffffd94c, 
    perror_object=0x7fffffffd950) at psi/interp.c:468
#13 0x00000000004f4329 in gs_main_interpret (perror_object=<optimized out>, pexit_code=<optimized out>, user_errors=-9904, pref=0x7fffffffd920, minst=<optimized out>)
    at psi/imain.c:247
#14 gs_main_run_string_end (minst=minst@entry=0x160d0f0, user_errors=<optimized out>, pexit_code=pexit_code@entry=0x7fffffffd94c, 
    perror_object=perror_object@entry=0x7fffffffd950) at psi/imain.c:660
#15 0x00000000004f43ae in gs_main_run_string_with_length (minst=minst@entry=0x160d0f0, str=str@entry=0x16e1100 "<746573742e706466>.runfile", length=<optimized out>, 
    user_errors=<optimized out>, pexit_code=pexit_code@entry=0x7fffffffd94c, perror_object=perror_object@entry=0x7fffffffd950) at psi/imain.c:618
#16 0x00000000004f43ed in gs_main_run_string (minst=minst@entry=0x160d0f0, str=str@entry=0x16e1100 "<746573742e706466>.runfile", user_errors=<optimized out>, 
    pexit_code=pexit_code@entry=0x7fffffffd94c, perror_object=perror_object@entry=0x7fffffffd950) at psi/imain.c:600
#17 0x00000000004f5949 in run_string (minst=minst@entry=0x160d0f0, str=str@entry=0x16e1100 "<746573742e706466>.runfile", options=options@entry=3) at psi/imainarg.c:988
#18 0x00000000004f5ac8 in runarg (minst=0x160d0f0, pre=0x97e29d "", arg=<optimized out>, post=0x8c1bbd ".runfile", options=3) at psi/imainarg.c:978
#19 0x00000000004f763b in gs_main_init_with_args (minst=minst@entry=0x160d0f0, argc=argc@entry=7, argv=argv@entry=0x7fffffffe538) at psi/imainarg.c:239
#20 0x000000000046e062 in main (argc=7, argv=0x7fffffffe538) at psi/gs.c:96
(gdb)
Comment 5 Karl 2015-03-11 02:52:20 UTC
Created attachment 11506 [details]
gdb log with thread apply all backtrace full
Comment 6 Chris Liddell (chrisl) 2015-03-11 06:16:56 UTC
When you built from source, did you use the third party library code we include in the source distribution?
Comment 7 Karl 2015-03-11 06:29:32 UTC
I used this spec to build the rpm on one server and then installed it on the other:
https://build.opensuse.org/package/show?project=openSUSE%3A13.2&package=ghostscript

I assume that the spec is using the third party libs you are mentioning.
Comment 8 Chris Liddell (chrisl) 2015-03-11 06:42:29 UTC
(In reply to bugzilla from comment #7)
> I used this spec to build the rpm on one server and then installed it on the
> other:
> https://build.opensuse.org/package/show?project=openSUSE%3A13.
> 2&package=ghostscript
> 
> I assume that the spec is using the third party libs you are mentioning.

I don't really know anything about rpm, how to make them, or what the spec file means. Generally, distributions remove the third party libraries we supply in favour of using the ones already on the system which, in cases like this, can often introduce too many variables for us to be able to reproduce the problem.

Can you post the results of running ldd on the working and non-working executables on their respective machines?

And is this problem isolated to one machine?
Comment 9 Karl 2015-03-11 08:45:34 UTC
I have access to four rented machines in a datacenter. I have two machines with the same label, like XY50. Then I have one machine with label AB60 and CD70.

Both machines with XY50 give the error, the machines AB60 and CD70 are generating the images without problems. If I add -dNOTRANSPARENCY on XY50, there is no segfault anymore.

I can give you ssh access to one of the erroring machine if needed via PM.

LDD
From working machine:
# ldd /usr/bin/gs
        linux-vdso.so.1 (0x00007fff463fc000)
        libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00007f8c7ad9c000)
        libcups.so.2 => /usr/lib64/libcups.so.2 (0x00007f8c7ab45000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f8c7a940000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f8c7a63f000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f8c7a401000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8c7a1e3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f8c79e3b000)
        libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f8c79bc6000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f8c79988000)
        libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f8c79733000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f8c794eb000)
        libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f8c79283000)
        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f8c78e60000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f8c78c4a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f8c7afbd000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f8c789b3000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f8c78789000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f8c78563000)
        libjbig.so.2 => /usr/lib64/libjbig.so.2 (0x00007f8c78356000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f8c78085000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f8c77e55000)                                                                                            
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f8c77c50000)                                                                                                  
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f8c77a43000)                                                                                      
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f8c7783e000)                                                                                                
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f8c77627000)                                                                                                    
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f8c77403000)                                                                                                  
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f8c77198000)

From erroring machine:
# ldd /usr/bin/gs
        linux-vdso.so.1 (0x00007fff2cb6b000)
        libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00007f67476e7000)
        libcups.so.2 => /usr/lib64/libcups.so.2 (0x00007f6747490000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f674728b000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6746f8a000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f6746d4c000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6746b2e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6746787000)
        libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f6746512000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f67462d4000)
        libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f674607f000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f6745e37000)
        libssl.so.1.0.0 => /lib64/libssl.so.1.0.0 (0x00007f6745bcf000)
        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f67457ac000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f6745596000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6747908000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f67452ff000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f67450d5000)
        liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f6744eaf000)
        libjbig.so.2 => /usr/lib64/libjbig.so.2 (0x00007f6744ca2000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f67449d1000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f67447a1000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f674459c000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f674438f000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f674418a000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6743f73000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f6743d4f000)
        libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f6743ae4000)
Comment 10 Chris Liddell (chrisl) 2015-03-11 15:11:55 UTC
We may well have to take you up on the offer of access to your failing machine, but a bunch of us have just finished traveling, and the rest still have a day or so traveling to go, so it'll probably be a few days before one of us can get to it.
Comment 11 Michael Weiner 2015-03-11 17:45:47 UTC
Created attachment 11511 [details]
PDF file causing segmentation fault
Comment 12 Karl 2015-03-12 03:42:10 UTC
Chris, I have sent you a PM with the access.
Comment 13 jsmeix 2015-03-12 04:18:01 UTC
(In reply to Chris Liddell (chrisl) from comment #6)
> When you built from source, did you use the third party library code we
> include in the source distribution?

Chris Liddell,
regarding how we build Ghostscript in the openSUSE build service
for openSUSE 13.2 see the "build" section in its RPM spec file at

https://build.opensuse.org/package/view_file/openSUSE:13.2/ghostscript/ghostscript.spec?expand=1

that reads (excerpt):
----------------------------------------------------------------------------
autoreconf -fi
# --docdir=%%{_defaultdocdir}/%%{name} does not work therefore
#   it is not used.
# --enable-cups and --with-pdftoraster and --with-install-cups
#   (--with-install-cups is new since version 9.04)
#   to make and install cups/filter/gstoraster and cups/filter/gstopxl
#   and related files (gstoraster.convs pxlcolor.ppd pxlmono.ppd).
# --enable-dbus to have colord support in gstoraster,
#   see cups/colord.c (colord is accessed via D-Bus).
# --with-ijs to enable IJS printer driver support
#   (in particular needed by HPIJS).
# --with-drivers=ALL to all file format drivers and all printer drivers.
# --with-x to use the X Window System.
# --without-omni to disable the outdated and unmaintained omni driver.
# --without-jasper and --enable-openjpeg because since Ghostscript 9.05
#   JasPer is deprecated and Ghostscript now ships modified OpenJPEG
#   sources for JPEG2000 decoding (replacing JasPer - although JasPer
#   is still included for this release). Performance, reliability and
#   memory use whilst decoding JPX streams are all improved.
# --without-ufst and --without-luratech because those are relevant
#   to commercial releases only
#   which would require a commercial license.
# --without-libpaper disables libpaper support because SUSE does
#   not have libpaper.
%define gs_font_path /usr/share/fonts/truetype:/usr/share/fonts/Type1:/usr/share/fonts/CID:/usr/share/fonts/URW

[...]

./configure --prefix=%{_prefix} \
            --bindir=%{_bindir} \
            --libdir=%{_libdir} \
            --datadir=%{_datadir} \
            --mandir=%{_mandir} \
            --infodir=%{_infodir} \
            --with-fontpath=%{gs_font_path} \
            --with-libiconv=maybe \
            --enable-freetype \
            --with-jbig2dec \
            --without-jasper \
            --enable-openjpeg \
            --enable-dynamic \
            --with-ijs \
            --enable-cups \
            --enable-dbus \
            --with-pdftoraster \
            --with-install-cups \
            --with-drivers=ALL \
            --with-x \
            --disable-gtk \
            --disable-compile-inits \
            --without-omni \
            --without-ufst \
            --without-luratech \
            --without-libpaper
make
# Make libgs.so and two programs which use it, gsx and gsc:
make so
# Configure and make libijs (that is not done regardless
# whether or not --with-ijs is used above):
pushd ijs
./autogen.sh
./configure --prefix=%{_prefix} \
            --bindir=%{_bindir} \
            --libdir=%{_libdir} \
            --datadir=%{_datadir} \
            --mandir=%{_mandir} \
            --infodir=%{_infodir} \
            --enable-shared \
            --disable-static
make
popd
----------------------------------------------------------------------------
Those commands are executed in the build system to compile Ghostscript.

I try as good as I can to build Ghostscript in full compliance
with upstream but I am always uncertain what exactly it means
to build Ghostscript in full compliance with upstream.

At least I failed to find documentation what exact configure
settings would result that Ghostscript is no longer in full
compliance with upstream.

I know about
http://ghostscript.com/doc/current/thirdparty.htm
but it does not make clear what third party library code from
the Ghostscript sources is mandatory to build Ghostscript in
full compliance with upstream.

I guess those third party library code from the Ghostscript
sources that are marked "with patches" are required to be used
from the Ghostscript sources when building it in full compliance
with upstream.
Comment 14 Chris Liddell (chrisl) 2015-03-13 11:22:30 UTC
I have had a look at the failing and non-failing machine (thanks!). It seems to be related to how we've "faked" recursive mutexes. It relies on it being safe to release an already released mutex, which is, in general, not the case. pthreads states that unlocking an already unlocked mutex is is undefined, so we should really not rely on that!

A hacky fix would be to initialise our mutexes as "error checking", rather than "fast", but I feel a better solution would be to properly emulate recursive mutexes.

The crashing/not-crashing is baffling: on the crashing machine, we end up going through what appears to be a highly optimised code path in pthreads, which does almost no error checking, whilst on the non-crashing machine we go through a much more robust code path, which does error check (including if the mutex is already unlocked). I cannot see what causes that difference, but as the root cause is an error in our code, I didn't spend long on that.

I have coded proper recursive mutex emulation, but I need to test it properly, which I will do next week - then throw up the code for review.
Comment 15 Chris Liddell (chrisl) 2015-03-14 05:52:05 UTC
*** Bug 695868 has been marked as a duplicate of this bug. ***
Comment 16 Chris Liddell (chrisl) 2015-03-17 07:19:02 UTC
Fixed in:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=444e0bf9
Comment 17 Chris Liddell (chrisl) 2015-03-17 07:50:03 UTC
(In reply to Chris Liddell (chrisl) from comment #16)
> Fixed in:
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=444e0bf9

But also requires:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3dbcbb2

(sorry!).
Comment 18 Karl 2015-03-19 03:32:23 UTC
Thanks Chris for the fix!

Is it possible to use the diffs for 9.15? Or is git head production ready in order to fix the issue on my machine? Or is there any other preferred workaround?
Comment 19 Chris Liddell (chrisl) 2015-03-19 03:49:12 UTC
(In reply to bugzilla from comment #18)
> Thanks Chris for the fix!
> 
> Is it possible to use the diffs for 9.15? Or is git head production ready in
> order to fix the issue on my machine? Or is there any other preferred
> workaround?

We are due to release 9.16 shortly, so it *should* be stable, *but* it hasn't been through our release testing yet, so, YMMV.

You have a few alternative options:

1) you can use HEAD with the above caveat.

2) you can wait a couple of weeks or so and get 9.16 when it is released

3) you can tweak the 9.15 build (get a clean source tree, run configure, open Makefile and change the line "SYNC=posync" to be "SYNC=nosync", and build). That disables the ability to do multithreaded rendering, but in general that's not a huge problem.


finally,


4) you can grab the file gs/base/gp_psync.c from HEAD and that *should* work in the 9.15 source base (use HEAD, as I had to tweak things a little after the above commits).


If it were me, I would do either "2" or "3" above.
Comment 20 Ken Sharp 2015-03-23 03:09:43 UTC
*** Bug 695881 has been marked as a duplicate of this bug. ***