Summary: | PostScript to tiffg4 bus error core dump | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | George Norris <george.norris> |
Component: | General | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex, chris.liddell |
Priority: | P4 | ||
Version: | 9.04 | ||
Hardware: | Sun | ||
OS: | SunOS | ||
Customer: | Word Size: | --- | |
Attachments: |
Zip file contiaining issue.ps, 2.ps and 3.ps
workaround patch Possible patch for gxht_thresh.c for review |
Description
George Norris
2011-09-27 19:41:25 UTC
I cannot reproduce this on Linux, AMD64 in v.9.04 or the current development version. Valgrind doesn't show anything relevant either. We are in the wonderful world of platform-dependent bugs. Please provide more information your copy of Ghostscript. Where did you get it? What compiler did you use? What gs was configured ? Do you have any unusual environment variables? No unusual environment variables. Here is the other information: The Ghostscript, that we are using was downloaded from: http://sourceforge.net/projects/ghostscript/files/GPL%20Ghostscript/9.04 I used the following to build it: ./configure --prefix=$PREFIX --without-jbig2dec --disable-fontconfig --disable-compile-inits --without-libiconv --with-fontpath=$FONTPATH It was built on Solaris 5.10 Generic_137137-09 sun4u sparc SUNW using gmake GNU make 3.80 The compiler is gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Thread model: posix Let me know if you nee any other information. Thanks... We have gs 9.04 installed on Linux and SUN. We found that it did not happen on the Linux box. So, I can confirm that it sppears to be platform specific to SUN boxes. Reassigning to Chris, who has access to a Sparc box. I can reproduce the problem on my Solaris/Sparc box. More when I have it...... Created attachment 7968 [details]
workaround patch
I have found the problem, but I don't yet have a solution.
However, I've attached a patch which is a workaround (it removes a performance optimisation which is primarily aimed at PCL input). It will get you up and running until a full fix is available.
Created attachment 7977 [details]
Possible patch for gxht_thresh.c for review
I've taken this about as far as I can, it really needs Michael's eye cast over it now.
The crash happens in gdevm1.c at line 672. Inside that macro is a loop (yuck!), and the bus error occurs because we're dereferencing a uint * at an unaligned address on the second iteration of the loop. This stems from the stride of the source bitmap being 45, so that, although the base address of the bitmap is aligned to 4 bytes, subsequent scanlines (probably) are not. SPARC being one of the few platforms that strictly enforces pointer alignment.
The source of the problem is actually in gxht_thresh.c, the function gxht_thresh_image_init(), where the penum->line_size and penum->ht_stride are not calculated to account for pointer alignment.
Also, it looks to me as if there is an invalid assumption made, that mem_mono_copy_mono() writes samples in 16 bit (ushort) "chunks" - that is only true on little-endian platforms. On big-endian platforms, we write 32 bit (uint) "chunks" (see line 499 in gdevm1.c).
The attached patch uses the "bitmap_raster()" macro to calculate the stride (to be consistent with other raster memory allocations), and also changes what I *think* may be required to deal with the extra unaligned bits at the beginning of the area being marked (the value of penum->ht_offset_bits is set using "bitmap_raster()" to get appropriate alignment for the value). This will overestimate the value, but I *think* it's a small price for consistent code.
The patch fixes the problem on SPARC, and a cluster run shows, *I think*, no new indeterminisms. One caveat is that I don't know if there are other places in the code which make assumptions about the values being setup as they are without this patch.
Just ping me if you need me to run tests on a SPARC machine.
Chris, The patch looks reasonable to me. I agree that I should have been using bitmap_raster to calculate the stride. Do you want me to move forward with this or do you want to test and verify and commit since you did all the work? Michael, Wow I didn't expect you to get to this until you'd been back a few days. I'm quite happy to take responsibility/blame for it - I've done quite a lot of testing of the fix, so I think between that, and your confirmation that it doesn't look insane, we're good. I *would* like to run more general testing on the SPARC - clearly, it's the only platform we currently have around which is strict with alignment, but that is, I think, separate from this bug. I'll commit later today. |