ImageMagick maybe broken by libgs9 upgrade

ImageMagick maybe broken by libgs9 upgrade

[Emily]

I use ImageMagick to convert and crop shipping labels from PDFs generated by Ebay.  On 6/8, this command worked:

$ convert -density 300 -crop 1500x1200 label.pdf label.png
Aborted (core dumped)


The command still runs on PDFs that were not generated by Ebay, but I get the same error on old Ebay PDF files (from 6/8 and earlier) that previously converted and cropped without problems.


This is in my /var/log/setup.log:

2020/06/09 19:52:15   29 install libgs9                9.52-2
2020/06/09 19:52:15   30   erase libgs9                9.27-2


Cropping in a separate step after converting to PNG still works:

$ convert -density 300 label.pdf temp.png
$ convert -crop 1500x1200 temp.png label.png


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.

Thanks for your help!
Emily

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

On 6/22/2020 9:37 PM, Emily via Cygwin wrote:
> I use ImageMagick to convert and crop shipping labels from PDFs generated by Ebay.  On 6/8, this command worked:
> 
> $ convert -density 300 -crop 1500x1200 label.pdf label.png
> Aborted (core dumped)
> 
> 
> The command still runs on PDFs that were not generated by Ebay, but I get the same error on old Ebay PDF files (from 6/8 and earlier) that previously converted and cropped without problems.
> 
> 
> This is in my /var/log/setup.log:
> 
> 2020/06/09 19:52:15   29 install libgs9                9.52-2
> 2020/06/09 19:52:15   30   erase libgs9                9.27-2
> 
> 
> Cropping in a separate step after converting to PNG still works:
> 
> $ convert -density 300 label.pdf temp.png
> $ convert -crop 1500x1200 temp.png label.png
> 
> 
> 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.

Thanks.

Ken

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

On 6/23/2020 7:27 AM, Ken Brown via Cygwin wrote:
> On 6/22/2020 9:37 PM, Emily via Cygwin wrote:
>> I use ImageMagick to convert and crop shipping labels from PDFs generated by 
>> Ebay.  On 6/8, this command worked:
>>
>> $ convert -density 300 -crop 1500x1200 label.pdf label.png
>> Aborted (core dumped)
>>
>>
>> The command still runs on PDFs that were not generated by Ebay, but I get the 
>> same error on old Ebay PDF files (from 6/8 and earlier) that previously 
>> converted and cropped without problems.
>>
>>
>> This is in my /var/log/setup.log:
>>
>> 2020/06/09 19:52:15   29 install libgs9                9.52-2
>> 2020/06/09 19:52:15   30   erase libgs9                9.27-2
>>
>>
>> Cropping in a separate step after converting to PNG still works:
>>
>> $ convert -density 300 label.pdf temp.png
>> $ convert -crop 1500x1200 temp.png label.png
>>
>>
>> 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

Re: ImageMagick maybe broken by libgs9 upgrade

[Markus Hoenicka]

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:
>>> I use ImageMagick to convert and crop shipping labels from PDFs 
>>> generated by Ebay.  On 6/8, this command worked:
>>> 
>>> $ convert -density 300 -crop 1500x1200 label.pdf label.png
>>> Aborted (core dumped)
>>> 
>>> 
>>> The command still runs on PDFs that were not generated by Ebay, but I 
>>> get the same error on old Ebay PDF files (from 6/8 and earlier) that 
>>> previously converted and cropped without problems.
>>> 
>>> 
>>> This is in my /var/log/setup.log:
>>> 
>>> 2020/06/09 19:52:15   29 install libgs9                9.52-2
>>> 2020/06/09 19:52:15   30   erase libgs9                9.27-2
>>> 
>>> 
>>> Cropping in a separate step after converting to PNG still works:
>>> 
>>> $ convert -density 300 label.pdf temp.png
>>> $ convert -crop 1500x1200 temp.png label.png
>>> 
>>> 
>>> 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

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

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

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

[-- 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 --]

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

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

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 23.06.2020 22:56, Ken Brown via Cygwin wrote:
> 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

Noted.

Regards
MArco

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 23.06.2020 23:02, Marco Atzeri wrote:
> On 23.06.2020 22:56, Ken Brown via Cygwin wrote:
>>
>> 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
> 
> Noted.
> 
> Regards
> MArco
> 

a test ImageMagick-6.9.10.11-3 is going up.
Let me know if it solves the problem

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

On 6/24/2020 1:30 AM, Marco Atzeri via Cygwin wrote:
> On 23.06.2020 23:02, Marco Atzeri wrote:
>> On 23.06.2020 22:56, Ken Brown via Cygwin wrote:
>>>
>>> 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
>>
>> Noted.
>>
>> Regards
>> MArco
>>
> 
> a test ImageMagick-6.9.10.11-3 is going up.
> Let me know if it solves the problem

That fixes it for my .eps file.  I didn't think of it before, but a similar 
patch to coders/pdf.c:201 will be needed for .pdf files.  I won't be able to 
test that because I haven't found a .pdf file that exhibits the problem.

Ken

Ken

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 24.06.2020 12:24, Ken Brown via Cygwin wrote:
> On 6/24/2020 1:30 AM, Marco Atzeri via Cygwin wrote:
>> On 23.06.2020 23:02, Marco Atzeri wrote:
>>> On 23.06.2020 22:56, Ken Brown via Cygwin wrote:
>>>>
>>>> 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
>>>
>>> Noted.
>>>
>>> Regards
>>> MArco
>>>
>>
>> a test ImageMagick-6.9.10.11-3 is going up.
>> Let me know if it solves the problem
> 
> That fixes it for my .eps file.  I didn't think of it before, but a 
> similar patch to coders/pdf.c:201 will be needed for .pdf files.  I 
> won't be able to test that because I haven't found a .pdf file that 
> exhibits the problem.
> 
> Ken
> 


test version 6.9.10.11-4 is going up.

If Emily tests with her pdf files, it will be nice

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Emily]

Hi Marco, I don't see that one, do I need to add a special download site?  Thanks!



On Wednesday, June 24, 2020, 11:21:59 AM PDT, Marco Atzeri <marco.atzeri@gmail.com> wrote: 

On 24.06.2020 12:24, Ken Brown via Cygwin wrote:
> On 6/24/2020 1:30 AM, Marco Atzeri via Cygwin wrote:
>> On 23.06.2020 23:02, Marco Atzeri wrote:
>>> On 23.06.2020 22:56, Ken Brown via Cygwin wrote:
>>>>
>>>> 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
>>>
>>> Noted.
>>>
>>> Regards
>>> MArco
>>>
>>
>> a test ImageMagick-6.9.10.11-3 is going up.
>> Let me know if it solves the problem
> 
> That fixes it for my .eps file.  I didn't think of it before, but a 
> similar patch to coders/pdf.c:201 will be needed for .pdf files.  I 
> won't be able to test that because I haven't found a .pdf file that 
> exhibits the problem.
> 
> Ken
> 


test version 6.9.10.11-4 is going up.

If Emily tests with her pdf files, it will be nice

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

On 6/24/2020 2:46 PM, Emily via Cygwin wrote:
> Hi Marco, I don't see that one, do I need to add a special download site?  Thanks!

You might not have waited long enough for it to propagate to the mirrors.  But I 
just checked mirrors.kernel.org, and it's there.  Since it's a test package, 
you'll have to explicitly select the version you want.  In addition to 
ImageMagick, you'll have to update libMagickCore6_6 and libMagickWand6_6.

Ken

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 24.06.2020 20:46, Emily wrote:
> Hi Marco, I don't see that one, do I need to add a special download site?  Thanks!
> 

just uploaded on the main site

wait a bit for the mirror sites to synchronize

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 25.06.2020 22:51, Emily wrote:
> I switched to mirrors.kernel.org, and still don't see an 11-4, screenshot attached.  Is there a setting that hides test packages?
> 
> 

My fault. I built and uploaded only the 64bit version
as I was in the hurry

It seems you are still on 32bit.

building it, now

Sorry
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Marco Atzeri]

On 26.06.2020 05:38, Marco Atzeri wrote:
> On 25.06.2020 22:51, Emily wrote:
>> I switched to mirrors.kernel.org, and still don't see an 11-4, 
>> screenshot attached.  Is there a setting that hides test packages?
>>
>>
> 
> My fault. I built and uploaded only the 64bit version
> as I was in the hurry
> 
> It seems you are still on 32bit.
> 
> building it, now
> 
> Sorry
> Marco
> 

32bit also up

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Emily]

Thanks to Ken, and Marco, and everyone who provided input.  I confirm that my original command is working again with the 11-4 version on my Ebay PDFs.  I truly appreciate the quick response and fix!

 Best wishes!
Emily


 On Thursday, June 25, 2020, 9:00:32 PM PDT, Marco Atzeri <marco.atzeri@gmail.com> wrote: 
On 26.06.2020 05:38, Marco Atzeri wrote:
> On 25.06.2020 22:51, Emily wrote:
>> I switched to mirrors.kernel.org, and still don't see an 11-4, 
>> screenshot attached.  Is there a setting that hides test packages?
>>
>>
> 
> My fault. I built and uploaded only the 64bit version
> as I was in the hurry
> 
> It seems you are still on 32bit.
> 
> building it, now
> 
> Sorry
> Marco
> 

32bit also up

Regards

Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[marco atzeri]

On Fri, 26 Jun 2020, 07:47 Emily, <emilyw@yahoo.com> wrote:

> Thanks to Ken, and Marco, and everyone who provided input.  I confirm that
> my original command is working again with the 11-4 version on my Ebay
> PDFs.  I truly appreciate the quick response and fix!
>
>  Best wishes!
> Emily
>
>
> Thanks for the confirmation.
I will change 4 to default, next week, when I am back

Regards
Marco

Re: ImageMagick maybe broken by libgs9 upgrade

[Lemures Lemniscati]

Date: Tue, 23 Jun 2020 08:15:01 -0400
From: Ken Brown via Cygwin <cygwin@cygwin.com>

> On 6/23/2020 7:27 AM, Ken Brown via Cygwin wrote:
> > On 6/22/2020 9:37 PM, Emily via Cygwin wrote:
> >> I use ImageMagick to convert and crop shipping labels from PDFs generated by
> >> Ebay.  On 6/8, this command worked:
> >>
> >> $ convert -density 300 -crop 1500x1200 label.pdf label.png
> >> Aborted (core dumped)
> >>
> >>
> >> The command still runs on PDFs that were not generated by Ebay, but I get the
> >> same error on old Ebay PDF files (from 6/8 and earlier) that previously
> >> converted and cropped without problems.
> >>
> >>
> >> This is in my /var/log/setup.log:
> >>
> >> 2020/06/09 19:52:15   29 install libgs9                9.52-2
> >> 2020/06/09 19:52:15   30   erase libgs9                9.27-2
> >>
> >>
> >> Cropping in a separate step after converting to PNG still works:
> >>
> >> $ convert -density 300 label.pdf temp.png
> >> $ convert -crop 1500x1200 temp.png label.png
> >>
> >>
> >> 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.
> 

How about something like:

convert -density 300 label.pdf -crop 1500x1200+0+0 label.png

Lem

Re: ImageMagick maybe broken by libgs9 upgrade

[Emily]

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

Hi Ken,

Any actual label.pdf would contain the Ebay buyer's name and address, and my return address.  Is there a tool I can use to redact sensitive information in a PDF?

I am attaching two files: debug.txt is the output of adding `-debug all` to the convert command, and convert.exe.stackdump is a file that appears when I get the core dumped error message.

Maybe invoking Ghostscript directly will help narrow down the problem.  What's the equivalent gs command?

Thanks!
Emily


 On Tuesday, June 23, 2020, 5:15:04 AM PDT, Ken Brown <kbrown@cornell.edu> wrote: 
On 6/23/2020 7:27 AM, Ken Brown via Cygwin wrote:
> On 6/22/2020 9:37 PM, Emily via Cygwin wrote:
>> I use ImageMagick to convert and crop shipping labels from PDFs generated by 
>> Ebay.  On 6/8, this command worked:
>>
>> $ convert -density 300 -crop 1500x1200 label.pdf label.png
>> Aborted (core dumped)
>>
>>
>> The command still runs on PDFs that were not generated by Ebay, but I get the 
>> same error on old Ebay PDF files (from 6/8 and earlier) that previously 
>> converted and cropped without problems.
>>
>>
>> This is in my /var/log/setup.log:
>>
>> 2020/06/09 19:52:15   29 install libgs9                9.52-2
>> 2020/06/09 19:52:15   30   erase libgs9                9.27-2
>>
>>
>> Cropping in a separate step after converting to PNG still works:
>>
>> $ convert -density 300 label.pdf temp.png
>> $ convert -crop 1500x1200 temp.png label.png
>>
>>
>> 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

[-- Attachment #2: debug.txt --]
[-- Type: text/plain, Size: 7641 bytes --]

2020-06-22T17:10:10-07:00 0:00.007 0.000u 6.9.10 Configure convert[1783]: utility.c/ExpandFilenames/954/Configure
  Command line: convert {-density} {300} {-crop} {1500x1200} {-debug} {all} {label.pdf} {label.png}
2020-06-22T17:10:10-07:00 0:00.011 0.016u 6.9.10 Policy convert[1783]: policy.c/IsRightsAuthorized/603/Policy
  Domain: Module; rights=Read; pattern="PDF" ...
2020-06-22T17:10:10-07:00 0:00.011 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/ImageMagick-6/coder.xml"
2020-06-22T17:10:10-07:00 0:00.012 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/lib/ImageMagick-6.9.10//config-Q16/coder.xml"
2020-06-22T17:10:10-07:00 0:00.012 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/etc/ImageMagick-6/coder.xml"
2020-06-22T17:10:10-07:00 0:00.013 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/doc/ImageMagick-6/coder.xml"
2020-06-22T17:10:10-07:00 0:00.014 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "C:\Users\emily\AppData\Local/ImageMagick/coder.xml"
2020-06-22T17:10:10-07:00 0:00.014 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.config/ImageMagick/coder.xml"
2020-06-22T17:10:10-07:00 0:00.015 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.magick/coder.xml"
2020-06-22T17:10:10-07:00 0:00.015 0.016u 6.9.10 Configure convert[1783]: coder.c/LoadCoderCache/818/Configure
  Loading coder configuration file "/etc/ImageMagick-6/coder.xml" ...
2020-06-22T17:10:10-07:00 0:00.020 0.016u 6.9.10 Policy convert[1783]: policy.c/IsRightsAuthorized/603/Policy
  Domain: Path; rights=Read; pattern="label.pdf" ...
2020-06-22T17:10:10-07:00 0:00.021 0.016u 6.9.10 Blob convert[1783]: blob.c/OpenBlob/2765/Blob
    read 3 magic header bytes
2020-06-22T17:10:10-07:00 0:00.022 0.016u 6.9.10 Cache convert[1783]: cache.c/DestroyPixelCache/1181/Cache
  destroy
2020-06-22T17:10:10-07:00 0:00.022 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/ImageMagick-6/magic.xml"
2020-06-22T17:10:10-07:00 0:00.023 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/lib/ImageMagick-6.9.10//config-Q16/magic.xml"
2020-06-22T17:10:10-07:00 0:00.023 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/etc/ImageMagick-6/magic.xml"
2020-06-22T17:10:10-07:00 0:00.024 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/doc/ImageMagick-6/magic.xml"
2020-06-22T17:10:10-07:00 0:00.025 0.016u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "C:\Users\emily\AppData\Local/ImageMagick/magic.xml"
2020-06-22T17:10:10-07:00 0:00.026 0.031u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.config/ImageMagick/magic.xml"
2020-06-22T17:10:10-07:00 0:00.026 0.031u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.magick/magic.xml"
2020-06-22T17:10:10-07:00 0:00.027 0.031u 6.9.10 Configure convert[1783]: magic.c/LoadMagicCache/796/Configure
  Loading magic configure file "/etc/ImageMagick-6/magic.xml" ...
2020-06-22T17:10:10-07:00 0:00.031 0.031u 6.9.10 Policy convert[1783]: policy.c/IsRightsAuthorized/603/Policy
  Domain: Path; rights=Read; pattern="label.pdf" ...
2020-06-22T17:10:10-07:00 0:00.032 0.031u 6.9.10 Blob convert[1783]: blob.c/OpenBlob/2765/Blob
    read 3 magic header bytes
2020-06-22T17:10:10-07:00 0:00.032 0.031u 6.9.10 Cache convert[1783]: cache.c/DestroyPixelCache/1181/Cache
  destroy
2020-06-22T17:10:10-07:00 0:00.033 0.031u 6.9.10 Policy convert[1783]: policy.c/IsRightsAuthorized/603/Policy
  Domain: Coder; rights=Read; pattern="PDF" ...
2020-06-22T17:10:10-07:00 0:00.036 0.031u 6.9.10 Policy convert[1783]: policy.c/IsRightsAuthorized/603/Policy
  Domain: Path; rights=Read; pattern="label.pdf" ...
2020-06-22T17:10:10-07:00 0:00.037 0.031u 6.9.10 Blob convert[1783]: blob.c/OpenBlob/2765/Blob
    read 3 magic header bytes
2020-06-22T17:10:10-07:00 0:00.037 0.031u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/588/Resource
  ...
2020-06-22T17:10:10-07:00 0:00.046 0.047u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/641/Resource
  Acquire /tmp/magick-1783Kaf-yzdbYlSE
2020-06-22T17:10:10-07:00 0:00.047 0.047u 6.9.10 Resource convert[1783]: resource.c/RelinquishUniqueFileResource/1200/Resource
  Relinquish /tmp/magick-1783Kaf-yzdbYlSE
2020-06-22T17:10:10-07:00 0:00.082 0.078u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/588/Resource
  ...
2020-06-22T17:10:10-07:00 0:00.085 0.078u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/641/Resource
  Acquire /tmp/magick-178339pwm3leUVdE
2020-06-22T17:10:10-07:00 0:00.085 0.078u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/ImageMagick-6/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.086 0.078u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/lib/ImageMagick-6.9.10//config-Q16/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.086 0.078u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/etc/ImageMagick-6/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.087 0.078u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/usr/share/doc/ImageMagick-6/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.088 0.094u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "C:\Users\emily\AppData\Local/ImageMagick/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.088 0.094u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.config/ImageMagick/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.089 0.094u 6.9.10 Configure convert[1783]: configure.c/GetConfigureOptions/685/Configure
  Searching for configure file: "/home/emily/.magick/delegates.xml"
2020-06-22T17:10:10-07:00 0:00.090 0.094u 6.9.10 Configure convert[1783]: delegate.c/LoadDelegateCache/2087/Configure
  Loading delegate configuration file "/etc/ImageMagick-6/delegates.xml" ...
2020-06-22T17:10:10-07:00 0:00.096 0.094u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/588/Resource
  ...
2020-06-22T17:10:10-07:00 0:00.099 0.094u 6.9.10 Resource convert[1783]: resource.c/AcquireUniqueFileResource/641/Resource
  Acquire /tmp/magick-1783qhQP_o5CJvAf
2020-06-22T17:10:10-07:00 0:00.099 0.094u 6.9.10 Resource convert[1783]: resource.c/RelinquishUniqueFileResource/1200/Resource
  Relinquish /tmp/magick-1783qhQP_o5CJvAf
2020-06-22T17:10:10-07:00 0:00.102 0.094u 6.9.10 Exception convert[1783]: utility.c/ShredFile/1820/Exception
  Failed to remove: /tmp/magick-178339pwm3leUVdE

[-- Attachment #3: convert.exe.stackdump --]
[-- Type: application/octet-stream, Size: 162 bytes --]

Stack trace:
Frame     Function  Args
0022DE9C  6102486E (00000230, 0000EA60, 000000A4, 0022DEFC)
0022DFBC  61105C49 (0022DFDC, 00000000, 00000000, 00000000)

Re: ImageMagick maybe broken by libgs9 upgrade

[Ken Brown]

Hi Emily,

On 6/23/2020 3:32 PM, Emily wrote:
> Any actual label.pdf would contain the Ebay buyer's name and address, and my return address.  Is there a tool I can use to redact sensitive information in a PDF?

There's no need.  I've found the bug, as I will explain in a separate message.

Ken