ImageMagick maybe broken by libgs9 upgrade
Ken Brown
kbrown@cornell.edu
Tue Jun 23 20:56:23 GMT 2020
On 6/23/2020 2:18 PM, Ken Brown via Cygwin wrote:
> 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.
I think I've found the problem, although it will take patching and rebuilding
ImageMagick (which I haven't done) to confirm that I'm right.
In the ImageMagick source file coders/ps.c:237, there's a call to
ghost_info->new_instance, a.k.a. gsapi_new_instance (see line 214). The
documentation of the latter in the ghostscript sources (psi/iapi.c:57) says that
the first argument pinstance should satisfy *pinstance == NULL in the first call
to that function.
But *pinstance in this call is the variable 'interpreter', defined without
initialization in ps.c:191. As a result, **pinstance contains garbage, and the
program eventually crashes when it tries to dereference a garbage pointer.
The fix, if I'm right, is to initialize interpreter to NULL in ps.c:191.
Ken
More information about the Cygwin
mailing list