SEGV with --with-gslib for 1.1.10

I've built 1.1.10 on RHEL4/x86_64 with --with-gslib against
Ghostscript 8.57. I'm getting a SEGV while running the testsuite:
  ./rwfile ./input_bilevel.miff JPEG
  ./rwfile ./input_gray.miff JPEG
  ./rwfile ./input_256c.miff JPEG
  ./rwfile ./input_truecolor.miff JPEG

  $ cd tests
  $ gdb .libs/rwfile core.1361
  ...
  Core was generated by `/opt/build/GraphicsMagick-1.1.10/tests/.libs/lt-rwfile ./input_bilevel.miff JPE'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x00002aaaab4423d4 in jpeg_alloc (cinfo=0x7fff877e8280, size=168, 
      info=0x2aaaab6e3a18 "JPEG small internal data allocation")
      at ./src/sjpegc.c:195
  195         jpeg_block_t *p = gs_alloc_struct_immovable(mem, jpeg_block_t,
  (gdb) bt
  #0  0x00002aaaab4423d4 in jpeg_alloc (cinfo=0x7fff877e8280, size=168, 
      info=0x2aaaab6e3a18 "JPEG small internal data allocation")
      at ./src/sjpegc.c:195
  #1  0x00002aaaab4425cc in jpeg_get_small (cinfo=0x7fff877e8280, size=168)
      at ./src/sjpegc.c:233
  #2  0x00002aaaac04a79a in jinit_memory_mgr (cinfo=0x7fff877e8280)
      at ./jmemmgr.c:1059
  #3  0x00002aaaac028536 in jpeg_CreateCompress (cinfo=0x7fff877e8280, 
      version=62, structsize=520) at ./jcapimin.c:58
  #4  0x00002aaaac88bf4a in WriteJPEGImage (image_info=0x186d1de0, 
      image=0x186961a0) at jpeg.c:1433
  #5  0x00002aaaaab391a9 in WriteImage (image_info=0x1868ff20, image=0x186961a0)
      at constitute.c:3207
  #6  0x000000000040168d in main (argc=3, argv=0x7fff877ea0c8) at rwfile.c:207


GM 1.1.10 built with --without-gslib passes the above tests. I can
duplicate the SEGV on other platforms, like AIX 5.3 and IRIX 6.5.

ImageMagick 6.3.6 built with --with-gslib on RHEL 4/x86_64 passes all
tests.
  ...
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_bilevel.miff JPEG 
  PASS: tests/rwfile_JPEG_bilevel.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_gray.miff JPEG 
  PASS: tests/rwfile_JPEG_gray.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_pallette.miff JPEG 
  PASS: tests/rwfile_JPEG_pallette.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_truecolor10.pam JPEG 
  PASS: tests/rwfile_JPEG_truecolor10.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_truecolor12.pam JPEG 
  PASS: tests/rwfile_JPEG_truecolor12.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_truecolor16.pam JPEG 
  PASS: tests/rwfile_JPEG_truecolor16.sh
  /opt/build/ImageMagick-6.3.6/tests/.libs/lt-rwfile /opt/build/ImageMagick-6.3.6/tests/input_truecolor.miff JPEG 
  PASS: tests/rwfile_JPEG_truecolor.sh
  ...

So, is GM doing something wrong or did we just build one of our
3rd-party libs incorrectly?

-- 
albert chin ([email protected])

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/