Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#38226 - [ghostscript] Segmentation Fault in OpenJPEG library.

Attached to Project: Arch Linux
Opened by Edward O'Callaghan (evocallaghan) - Sunday, 22 December 2013, 11:45 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 22 January 2014, 12:40 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



A full background can be found here:

Short Story:

openjpeg 1.5.1-1 is actually very out of date.

Building openjpeg 2.0.0 from source resolved the
segmentation fault issue with the ps2write device backend.

Hence could someone bump the version of the openjpeg library to
version 2.0.0 ?

Kind Regards,
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 22 January 2014, 12:40 GMT
Reason for closing:  Fixed
Comment by Jelle van der Waa (jelly) - Sunday, 22 December 2013, 13:14 GMT
openjpg2 is in the repos.
Comment by Edward O'Callaghan (evocallaghan) - Sunday, 22 December 2013, 15:29 GMT
Sure ok, however the issue is then;

cups-filters: requires poppler
poppler: requires openjpeg

I came across this while trying to print orginally.

Thus I guess, can poppler be update to link to openjpeg2
instead and why is it not already? Many issues were resolved
in 2.0.0 over 1.5.x after digging in.

Kind Regards,
Comment by Andreas Radke (AndyRTR) - Sunday, 22 December 2013, 21:12 GMT
Look at and;a=commit;h=66d9c0aa17a5abcecd6590e63f0620f7aa51634c

The code hasn't landed in GS 9.10 but only in git master. We will have to wait for a release including these fixes.
That's a major change we can't backport.
Comment by Edward O'Callaghan (evocallaghan) - Monday, 23 December 2013, 02:26 GMT
OK I do know however, that if I compile openjpeg 2.0.0 from source by adjusting the
PKGBUILD and overwrite the openjpeg 1.5.1-1 package the issue magically goes away.

It maybe prudent to add yourself to the upstream CC list Andreas Radke (AndyRTR) if you don't mind?
Since I really don't know how so many of these smaller component libraries work together in this particular case.

Kind Regards,
P.S. Thanks for looking into this.
Comment by Edward O'Callaghan (evocallaghan) - Monday, 23 December 2013, 12:38 GMT
After talking upstream it does sound like the best cause of action
for Andreas Radke (AndyRTR) as you are assigned to this would be to
communicate with upstream directly going forward.

There is plenty of background narrowing down the problem, although
not complete to the exact line admittedly. It should be trivial to
replicated with all the provided information provided in the upstream bug.

The issue seems a bit more complex than; `wait a couple of weeks for
GS to bump a new release, nothing to see here..`

Comment by Paul Bredbury (brebs) - Tuesday, 24 December 2013, 10:00 GMT seems quite clear:

"*our* version of the OpenJPEG libraries incorporates patches... *don't* use system shared libraries"

and comment 18:

"The only safe route is to build with our bundled (patched) versions."

So I would suggest trying to compile ghostscript *without* this line in ghostscript's PKGBUILD:

rm -rf jpeg libpng zlib jasper expat tiff lcms lcms2 freetype openjpeg cups/libs

And I suppose, also remove "--with-system-libtiff"
Comment by Edward O'Callaghan (evocallaghan) - Tuesday, 24 December 2013, 16:35 GMT
Paul Bredbury (brebs) solution is correct, I also rebuilt the package to confirm as to be sure.

This change also makes prints sharper looking as a added benefit.

P.S. Merry Capitalism :)
Comment by Andreas Radke (AndyRTR) - Monday, 20 January 2014, 16:57 GMT
We should try to keep benefits from linking to system libs wherever possible to gain lower memory footprint,
quick upstream security fixes and so on.

Checking the Fedora and Debian builds both also use system libraries for libjpeg and system openjpeg. Openjpeg seems to
be only needed at build time as a makedep. So it should be safe to use included openjpeg and keep using system libjpeg-turbo.

Can somebody who's affected please do a ghostscript rebuild with chaning the cleanup line in the PKGBUILD to:

rm -rf jpeg jpegxr libpng zlib jasper expat tiff lcms lcms2 freetype cups/libs

This would be the way I prefer it. If it still gives segfaults we can also try

rm -rf jpegxr libpng zlib jasper expat tiff lcms lcms2 freetype cups/libs - but this could lead to a much slower picture handling.

If you can confirm a minimum change we need to apply I'll push a package to our testing repo.
Comment by Andreas Radke (AndyRTR) - Tuesday, 21 January 2014, 18:54 GMT
Can you provide a simple test case with its command and file that gives reproducible segfaults so I can test locally?
Comment by Andreas Radke (AndyRTR) - Tuesday, 21 January 2014, 20:51 GMT
I've found the Absolute_OpenBSD_UNIX_for_the_Practical_Paranoid_1886411999.pdf you've mentioned in your bug report and I could easily print the file
from Evince to my virtual pdf printer without a segfault.

So I need a proper test case to be able to reproduce it. If you don't provide such use case I can't confirm a possible fix.
Comment by Andreas Radke (AndyRTR) - Tuesday, 21 January 2014, 21:27 GMT
I've found a test case: gsx PLANHALF.pdf - the file is from (see

I could solve it with gs 9.10-2 that is just going to our testing repo. Please check if it also solves your error/segfault.