Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown <kbrown@cornell.edu>]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

On 6/23/2020 12:56 PM, Marco Atzeri via Cygwin wrote:
> On 23.06.2020 15:03, Markus Hoenicka wrote:
>> On 2020-06-23 14:15, Ken Brown via Cygwin was heard to say:
>>> On 6/23/2020 7:27 AM, Ken Brown via Cygwin wrote:
>>>> On 6/22/2020 9:37 PM, Emily via Cygwin wrote:
> 
>>>>>
>>>>> But in case other ImageMagick functionality is also broken, this isn't a 
>>>>> permanent solution.  I tried to downgrade libgs9, but 9.27 is no longer an 
>>>>> option in setup, even after I added another mirror.
>>>>
>>>> Please provide a sample label.pdf for which you're seeing this behavior.
>>>
>>> You could also try adding the '-verbose' option to your command line
>>> to see if that gives a clue.
>>>
>>> Ken
>>
>> Hi,
>>
>> I don't know whether this helps to track down the problem, but here goes 
>> anyway: I see the same crash with .ps and .eps files (unsurprisingly, as these 
>> and .pdf are processed by libgs). The same conversions work with "gm convert" 
>> from the GraphicsMagick package. gm is not linked against libgs, but seems to 
>> invoke the gs executable instead. This does not crash, although it is linked 
>> against the very same libgs.
>>
>> regards,
>> Markus
>>
> 
> 
> without a sample case we don't know if we need to rebuild ImageMagick
> or GS

I found a .eps file with which I could reproduce the crash (attached), using the 
OP's command line with her .pdf file replaced by the attached .eps file.  Here's 
the gdb backtrace after the crash:

Thread 1 "convert" received signal SIGSEGV, Segmentation fault.
gs_lib_ctx_init (ctx=ctx@entry=0xfffeed30, mem=mem@entry=0x8000987b0)
     at /usr/src/debug/ghostscript-9.52-2/base/gslibctx.c:269
269             gx_monitor_enter((gx_monitor_t *)(pio->core->monitor));
(gdb) bt
#0  gs_lib_ctx_init (ctx=ctx@entry=0xfffeed30, mem=mem@entry=0x8000987b0)
     at /usr/src/debug/ghostscript-9.52-2/base/gslibctx.c:269
#1  0x00000003ca37e0a3 in gs_malloc_init_with_context (ctx=0xfffeed30)
     at /usr/src/debug/ghostscript-9.52-2/base/gsmalloc.c:595
#2  0x00000003ca439da6 in psapi_new_instance (pinstance=0xfffee938,
     caller_handle=0xfffee930)
     at /usr/src/debug/ghostscript-9.52-2/psi/psapi.c:92
#3  0x00000003ca49e995 in gsapi_new_instance (pinstance=<optimized out>,
     caller_handle=<optimized out>)
     at /usr/src/debug/ghostscript-9.52-2/psi/iapi.c:64
#4  0x00000003fd2f53dc in InvokePostscriptDelegate (verbose=MagickFalse,
     command=command@entry=0xfffeed30 "'gs' -sstdout=%stderr -dQUIET -dSAFER -dBAT
CH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-s
DEVICE=pngalpha' -dTextAlphaBits=4 -dGraphicsAlphaBits=4 '-r300x300' -g196x2"...,
  message=message@entry=0xffff3d30 "", exception=exception@entry=0x8000664a0)
     at /usr/src/debug/ImageMagick-6.9.10.11-2/coders/ps.c:237
#5  0x00000003fd2f6234 in ReadPSImage (image_info=0x800076170,
     exception=0x8000664a0)
     at /usr/src/debug/ImageMagick-6.9.10.11-2/coders/ps.c:846

The crash occurs because of an attempt to access ridiculously high memory:

(gdb) p pio->core
$8 = (gs_lib_ctx_core_t *) 0x73253d74756f6474

I'm looking into it.

Ken

[-- Attachment #2: TCstep1.eps --]
[-- Type: application/postscript, Size: 3784 bytes --]