Summary: | seg fault under amd64 linux | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | ivo welch <ivo.welch> |
Component: | General | Assignee: | Default assignee <ghostpdl-bugs> |
Status: | NOTIFIED FIXED | ||
Severity: | critical | CC: | htl10, kili, Pavel.Pokorny, schultz, subrahmanyan-h.kalathur |
Priority: | P2 | ||
Version: | 8.54 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | 130 | Word Size: | --- |
Attachments: |
example pdf which triggers the problem
patch |
Description
ivo welch
2006-05-26 12:02:28 UTC
Please attach a file that can be used to reproduce this. Created attachment 2226 [details] example pdf which triggers the problem Just noticed mentions of the bug on irc. I have an opteron box (in fact my main work machine - running fedora core 5), and upgraded to 8.54 and picked a random pdf in my hard disc (original url http://cran.r-project.org/doc/FAQ/R-FAQ.pdf). I routinely build both 32-bit and 64-bit binaries on opteron (and uses the 32-bit one mostly) so I have a few RPMs lying around, here are the result on x86_64 linux: 8.54 64-bit - segfault 8.54 32-bit - work ok 8.53 64-bit - work ok 8.53 32-bit - work ok 8.15.2 64-bit - work ok work around: build ghostscript as a 32-bit binary. (adding -m32 on CFLAGS and a few other changes - the default is 64-bit). gdb backtrace: gdb /usr/local/bin/gs GNU gdb Red Hat Linux (6.3.0.0-1.122rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run -sDEVICE=pdfwrite -sOutputFile=/tmp/a.pdf -dNOPAUSE -dBATCH cran.r-project.org/doc/FAQ/R-FAQ.pdf Starting program: /usr/local/bin/gs -sDEVICE=pdfwrite -sOutputFile=/tmp/a.pdf -dNOPAUSE -dBATCH cran.r-project.org/doc/FAQ/R-FAQ.pdf AFPL Ghostscript 8.54 (2006-05-17) Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 89. Page 1 ... ... Page 89 Program received signal SIGSEGV, Segmentation fault. compare_glyph_names (pg1=Variable "pg1" is not available. ) at ./src/gxfcopy.c:2372 2372 return bytes_compare(gn1->str.data, gn1->str.size, gn2->str.data, gn2->str.size); (gdb) bt #0 compare_glyph_names (pg1=Variable "pg1" is not available. ) at ./src/gxfcopy.c:2372 #1 0x00000032484315e7 in msort_with_tmp () from /lib64/libc.so.6 #2 0x0000003248431870 in qsort () from /lib64/libc.so.6 #3 0x00000000005d2743 in copied_order_font (font=Variable "font" is not available. ) at ./src/gxfcopy.c:2394 #4 0x00000000005c2258 in pdf_write_embedded_font (pdev=0x94fb18, pbfont=0xd671c8, FontBBox=0xf51034, rid=Variable "rid" is not available. ) at ./src/gdevpdtb.c:446 #5 0x00000000005c53b8 in pdf_finish_FontDescriptor (pdev=0x94fb18, pfd=0xf50fd8) at ./src/gdevpdtd.c:554 #6 0x00000000005cfdd3 in pdf_finish_font_descriptors (pdev=0x94fb18, finish_proc=0x5c5340 <pdf_finish_FontDescriptor>) at ./src/gdevpdtw.c:624 #7 0x00000000005d0533 in pdf_close_text_document (pdev=0x94fb18) at ./src/gdevpdtw.c:643 #8 0x00000000005965af in pdf_close (dev=0x94fb18) at ./src/gdevpdf.c:1079 #9 0x00000000005f1f96 in gs_closedevice (dev=0x94fb18) at ./src/gsdevice.c:505 #10 0x0000000000467737 in gs_main_finit (minst=0x8d74a0, exit_status=0, code=-101) at ./src/imain.c:859 #11 0x0000000000404653 in main (argc=6, argv=0x7fffffa37708) at ./src/gs.c:117 #12 0x000000324841ce54 in __libc_start_main () from /lib64/libc.so.6 #13 0x0000000000404559 in _start () #14 0x00007fffffa376f8 in ?? () #15 0x0000000000000000 in ?? () (gdb) I wonder if this is related to the alignment changes we made just before release. Can you try reverting http://ghostscript.com/pipermail/gs-cvs/2006-May/006532.html and see if that fixes the proplem? If so, can you attach a copy of obj/arch.h for the 64 bit build? hi ralph: forgive me, but this is beyond my expertise here. the gentoo builds do all of the install for me, and chances are that I would only screw things up and then confuse you with incorrect bug reports. /iaw Reversed the patch mentioned in comment 4 and it still segfaults at the same place. FWIW, obj/arch.h only differ by one line - reversing the patch results in this line being added: 11a12 > #define ARCH_ALIGN_STRUCT_MOD 8 curious the two backtraces (the original poster's and mine) are completely different, except for the qsort(). A shame the gentoo build wasn't compiled with debug info. Hin-Tak: Ok, thanks for checking. The important bit is whether all the other ARCH_ALIGN defines are also 8. If so, it's something else. No the ARCH_ALIGN_* are all over the place. Here is the content of unpatched stock 8.54: ============= /* Parameters derived from machine and compiler architecture. */ /* This file is generated mechanically by genarch.c. */ /* ---------------- Scalar alignments ---------------- */ #define ARCH_ALIGN_SHORT_MOD 2 #define ARCH_ALIGN_INT_MOD 4 #define ARCH_ALIGN_LONG_MOD 8 #define ARCH_ALIGN_PTR_MOD 8 #define ARCH_ALIGN_FLOAT_MOD 4 #define ARCH_ALIGN_DOUBLE_MOD 8 /* ---------------- Scalar sizes ---------------- */ #define ARCH_LOG2_SIZEOF_CHAR 0 #define ARCH_LOG2_SIZEOF_SHORT 1 #define ARCH_LOG2_SIZEOF_INT 2 #define ARCH_LOG2_SIZEOF_LONG 3 #define ARCH_SIZEOF_GX_COLOR_INDEX 8 #define ARCH_SIZEOF_PTR 8 #define ARCH_SIZEOF_FLOAT 4 #define ARCH_SIZEOF_DOUBLE 8 #define ARCH_FLOAT_MANTISSA_BITS 24 #define ARCH_DOUBLE_MANTISSA_BITS 53 /* ---------------- Unsigned max values ---------------- */ #define ARCH_MAX_UCHAR ((unsigned char)0xff + (unsigned char)0) #define ARCH_MAX_USHORT ((unsigned short)0xffff + (unsigned short)0) #define ARCH_MAX_UINT ((unsigned int)~0 + (unsigned int)0) #define ARCH_MAX_ULONG ((unsigned long)~0L + (unsigned long)0) /* ---------------- Miscellaneous ---------------- */ #define ARCH_IS_BIG_ENDIAN 0 #define ARCH_PTRS_ARE_SIGNED 0 #define ARCH_FLOATS_ARE_IEEE 1 #define ARCH_ARITH_RSHIFT 2 #define ARCH_CAN_SHIFT_FULL_LONG 1 #define ARCH_DIV_NEG_POS_TRUNCATES 1 ===================== Ok, the upshot is that ARCH_ALIGN_MEMORY_MOD isn't any different with the patch from comment #4 reverted. It looks like it's a different issue. if you would like, I can get you an account on my machine to try building ghostscript here. [I don't think gentoo has an easy feature to suggest including debug switches.] regards, /iaw The segfault seems to be due to change between r6668 and r6669 around end of March 2006. Double-checking at the moment and will probably have a look at the diff after that. From cvs/svn change log feed in my mailbox, Change set 6669 is: ============== Date: 2006-03-21 04:09:23 -0800 (Tue, 21 Mar 2006) New Revision: 6669 Modified: trunk/gs/src/gdevpdtb.c trunk/gs/src/gxfcopy.c trunk/gs/src/gxfcopy.h Log: Fix (pdfwrite) : Order embedded fonts against an indeterminizm. ============== This seems to agree with where the segfault on my x86_64 box is, but isn't quite the same as the original posters', so we might be talking about two bugs. The bug is quite shallow. Replace sizeof(int) to sizeof(*a) in the file gxfcopy.c, line qsort(a, cfdata->num_glyphs, sizeof(int), compare_glyph_names); My 64-bit Multia is too slow to check the fix today. Ivo Welch and Hin-Tak Leung, please check whether the fix helps. Created attachment 2228 [details]
patch
Fix incorrect element size argument of qsort(), that causes SEGV on the
platforns with sizeof(void *) != sizeof(int) since rev. 6669.
DIFFERENCES:
Testing now
On DEC Alpha the back trace looks like:
#0 0x1202a4820 in compare_glyph_names (pg1=0x12045f376, pg2=0x3) at
./src/gxfcopy.c:2372
#1 0x20000360960 in msort_with_tmp () from /lib/libc.so.6.1
#2 0x20000360af8 in qsort () from /lib/libc.so.6.1
warning: Hit beginning of text section without finding
warning: enclosing function for address 0x11ffff8e0
This is consistant with the nature of the bug and the back trace reported by
Hin-Tak Leung but different from the original back trace. To confirm that the
original issue is fixed Ivo Welch sould try the patch on his computer.
As expected, there's no differences when the patch is tested on a 32-bit box. Patch approved, please commit. Thanks, Alex. It wasn't easy, but I managed to figure out how to compile afpl 8.54 with the -g flag, and rerun it with the patch. Hooray---you fixed the problem. regards, /ivo The patch is committed to revision 6818. *** Bug 688845 has been marked as a duplicate of this bug. *** *** Bug 688848 has been marked as a duplicate of this bug. *** *** Bug 688852 has been marked as a duplicate of this bug. *** Adding customer info to this bug. When marking bugs duplicate, we need to make sure and manually carry the customer(s) and priority forward to the destination bug. In this case it isn't important unless the bug gets re-opened, but that has been known to happen. *** Bug 688950 has been marked as a duplicate of this bug. *** |