The command 'gs -r20 -q -dNOPAUSE -dBATCH -sDEVICE=jpeg -sOutputFile=/tmp/9393812_low.jpg /tmp/9393812.pdf' gose in core dump with some PDF files. Every day gs make the jpeg preview of hundreds PDF files. There are few case that gs goes in core dump. I can sent the PDF examples. The same PDF files are processed fine on windows XP platform and gs 8,64. We have installed the binary compiled version for SPARC/Solaris10.
Created attachment 5201 [details] Newspaper PDF Page 9393812 this command goes in core dump on SPARC/Solaris10 /usr/local/bin/gs -r20 -q -dNOPAUSE -dBATCH -sDEVICE=jpeg -sOutputFile=/tmp/9393812_low.jpg /tmp/9393812.pdf
The problem with this bug, libiconv bug, and a few other Solaris bugs is the access to a working Solaris system. I know about OpenSolaris but it doesn't work on a few different x86 boxes I tried. For a speedy resolution of this issue an account on an affected system is instrumental.
I have a UltraSPARC 60 running Solaris 10 and can will on this when I return from vacation next week (my Sparc isn't turned on and I can't do so remotely). What compiler was used? gcc or Sun Studio?
We have used the binary taken from the file ghostscript-8.64-sol10-sparc-local.gz. Due the bug 690614 that's a duplicate of bug 690584 we aren't able to compile ghostscript on our sun sparc solaris 10 machine: Release: 5.10 Kernel architecture: sun4u Application architecture: sparc Hardware provider: Sun_Microsystems Domain: Kernel version: SunOS 5.10 Generic_127111-11
I've been able to reproduce the problem with both a standard and debug build of gs864, here's the stack trace: (gdb) where #0 0x006a2020 in zoom_y (dst=0x1c47323, sizeofPixelOut=2, MaxValueOut=32760, tmp=0x1c473c0 "������������������������������������������������������������������������������������������������������"..., WidthOut=67, tmp_width=67, Colors=1, contrib=0x1c390d4, items=0x1c390e4) at base/siscale.c:379 #1 0x006a2a50 in s_IScale_process (st=0x1c39000, pr=0xffbfe1a8, pw=0xffbfe198, last=0) at base/siscale.c:524 #2 0x006596e0 in image_render_interpolate (penum=0x1c6df48, buffer=0x1111936 "����", '� <repeats 21 times>, "��, '� <repeats 16 times>, "�������������������������, '� <repeats 16 times>, "��������������������", '� <repeats 32 times>, "��������"..., data_x=0, iw=497, h=1, dev=0x1c49580) at base/gxiscale.c:597 #3 0x00648538 in gx_image1_plane_data (info=0x1c6df48, planes=0x1c49b9c, height=8, rows_used=0xffbfe450) at base/gxidata.c:208 #4 0x0064c7d4 in gx_image_plane_data_rows (info=0x1c6df48, planes=0x1c49b9c, height=8, rows_used=0xffbfe450) at base/gximage.c:181 #5 0x005e4c34 in gs_image_next_planes (penum=0x1c49ab0, plane_data=0xffbfe538, used=0xffbfe4e8) at base/gsimage.c:600 #6 0x001a5834 in image_file_continue (i_ctx_p=0x1069800) at psi/zimage.c:520 #7 0x0013ac08 in call_operator (op_proc=0x1a5530 <image_file_continue>, i_ctx_p=0x1069800) at psi/interp.c:111 #8 0x0013dc70 in interp (pi_ctx_p=0x1041b14, pref=0xffbfed58, perror_object=0xffbff048) at psi/interp.c:1158 #9 0x0013b404 in gs_call_interp (pi_ctx_p=0x1041b14, pref=0xffbfeee0, user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/interp.c:496 #10 0x0013b234 in gs_interpret (pi_ctx_p=0x1041b14, pref=0xffbfeee0, user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/interp.c:454 #11 0x0012a640 in gs_main_interpret (minst=0x1041ac0, pref=0xffbfeee0, user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/imain.c:214 #12 0x0012b618 in gs_main_run_string_end (minst=0x1041ac0, user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/imain.c:526 #13 0x0012b46c in gs_main_run_string_with_length (minst=0x1041ac0, str=0x10e48a0 "<2e2e2f4275673639303631332e706466>.runfile", length=42, user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/imain.c:484 #14 0x0012b3a0 in gs_main_run_string (minst=0x1041ac0, str=0x10e48a0 "<2e2e2f4275673639303631332e706466>.runfile", user_errors=1, pexit_code=0xffbff054, perror_object=0xffbff048) at psi/imain.c:466 #15 0x0012f10c in run_string (minst=0x1041ac0, str=0x10e48a0 "<2e2e2f4275673639303631332e706466>.runfile", options=3) at psi/imainarg.c:797 #16 0x0012f0b0 in runarg (minst=0x1041ac0, pre=0x6c1d20 "", arg=0x106f4c8 "../Bug690613.pdf", post=0x6c1de8 ".runfile", options=3) at psi/imainarg.c:788 #17 0x0012ecf4 in argproc (minst=0x1041ac0, arg=0xffbffd30 "../Bug690613.pdf") at psi/imainarg.c:723 #18 0x0012d020 in gs_main_init_with_args (minst=0x1041ac0, argc=8, argv=0xffbffbcc) at psi/imainarg.c:207 #19 0x0004e620 in main (argc=8, argv=0xffbffbcc) at psi/gs.c:77 (gdb)
It continues to fail with the current head (r9860).
Created attachment 5217 [details] Newspaper_PDF_9174783 I will provide to you other PDF files for help you to reproduce an test the bugs.
Created attachment 5218 [details] Newspaper_PDF_9184236 I will provide to you other PDF files for help you to reproduce an test the bugs.
Created attachment 5219 [details] Newspaper_PDF_Page_9184278 I will provide to you other PDF files for help you to reproduce an test the bugs.
Purify states the problem is a "MAW: Misaligned memory write" in zoom_y (siscale.c): Misaligned write of 2 bytes to 0x2811561 in the heap. Address 0x2811561 is 8241 bytes into a malloc'd block at 0x280f430 of 20024 bytes
Link errors caused by GNU iconv.h and system libraries is fixed by the rev. 9871. Now it's the time for the SEGV one.
Add output buffer alignment code to one of the image handling branches where it was omitted. Fix a SEGV on SPARC platform that cannot access misaligned data. The following patch has been committed as a rev. 9873. http://ghostscript.com/pipermail/gs-cvs/2009-July/009572.html Regression testing on PC shows no differences.
After thousand of PDF processed in a production environment I can confirm that the bug is closed. Thanks, great jobs.