Bug 692375 - Ghostscript built on Mac OS X lion breaks pkmraw output
Summary: Ghostscript built on Mac OS X lion breaks pkmraw output
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: Macintosh MacOS X
: P4 normal
Assignee: Marcos H. Woehrmann
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-26 16:32 UTC by Marcos H. Woehrmann
Modified: 2014-02-17 04:42 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2011-07-26 16:32:37 UTC
This is with both the release and debug builds and with various versions of Ghostscript.

See http://www.ghostscript.com/~marcos/test.png
Comment 1 Marcos H. Woehrmann 2011-07-26 16:40:01 UTC
I should have mentioned in m original message that it only happens with banding and not with all input files.  

Sample command line:

bin/gs -sDEVICE=pkmraw -o test.pkm -r300 -dMaxBitmap=10000 ./000516-1.pdf
Comment 2 Marcos H. Woehrmann 2011-07-27 06:34:25 UTC
The issue appears to be isolated to gdevprn.o.  

I took a copy of Ghostscript  9.02 complied with Snow Leopard and replaced each of the .o files one at a time with one compiled under Lion and relinked the gs binary.  The only .o file that broke pkmraw output was gdevprn.o.

As a double check I took Ghostscript 9.02 compiled with Lion and replaced each .o file in turn with one complied with Snow Leopard.  The output was broken unless the gdevprn.o was replaced with the Snow Leopard built one.
Comment 3 Alex Cherepanov 2011-07-29 23:01:53 UTC
Does the bug 692375 happen in debug or release build?
What is the compiler version on Lion? Perhaps, the bug can be reproduced
elsewhere.
Comment 4 Marcos H. Woehrmann 2011-08-02 16:42:44 UTC
The problem occurs with both the debug and and release builds.  The gcc used on Lion is:

i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

oddly the Snow Leopard gcc appears to be a bit newer:

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Comment 5 Marcos H. Woehrmann 2011-08-15 05:15:42 UTC
I checked and forcing Xcode to use the non-llvm compiler does work around the issue.  This can be done easily done for Ghostscript/GhostPDL by passing an option on the autogen.sh line:

  ./autogen.sh "CC=gcc-4.2"
Comment 6 Marcos H. Woehrmann 2011-08-15 08:02:46 UTC
This problem is indeed in gdevprn.c.  

Specifically the memcmp() in the function gdev_prn_maybe_realloc_memory() fails when it shouldn't because of padding in the gdev_prn_space_params structure.

This is demonstrated by the following code:

#include <stdio.h>
#include <stdlib.h>

typedef int bool;

typedef struct gx_band_params_s {
    bool page_uses_transparency; /* PDF 1.4 transparency is used on the page */
    int BandWidth;              /* (optional) band width in pixels */
    int BandHeight;             /* (optional) */
    long BandBufferSpace;       /* (optional) */
} gx_band_params_t;

typedef struct gdev_prn_space_params_s {
    long MaxBitmap;             /* max size of non-buffered bitmap */
    long BufferSpace;           /* space to use for buffer */
    gx_band_params_t band;      /* see gxclist.h */
    bool params_are_read_only;  /* true if put_params may not modify this struct */
} gdev_prn_space_params;

int main(void) {
  gdev_prn_space_params test1;
  gdev_prn_space_params test2;
  int t;
  
  test1.MaxBitmap=0;
  test1.BufferSpace=0;
  test1.band.page_uses_transparency=0;
  test1.band.BandWidth=0;
  test1.band.BandHeight=0;
  test1.band.BandBufferSpace=0;
  test1.params_are_read_only=0;

  test2=test1;

  t=memcmp(&test1,&test2,sizeof(test1));

  printf("%d\n",t);

  return(0);
}


When this code is compiled with the default gcc (i.e. gcc test.c) the program returns -255, but when complied with gcc-4.2 (gcc-4.2 test.c) it returns 0.  

Here's a web reference: http://c-faq.com/struct/compare.html
Comment 7 Marcos H. Woehrmann 2011-08-15 08:44:05 UTC
Fixed in 28f0da42.