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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
