Symptoms: I generated GhostScript 8.53 on IBM-AIX 5.1 with gcc (2.95.3) and xlc. When interpreting a PDF-File with JPX-Data, I get the message: AFPL Ghostscript 8.53 (2005-10-20) 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 1. Page 1 unable to decode JPX image data. **** Warning: File has insufficient data for an image. Error: /typecheck in --closefile-- On all other UNIX-platforms ( SUN, HP-UX, IRIX, Linux ) and Windows there is no problem! Are there any known bugs for IBM-AIX ( compiler flags ? configuration ? ). What else could be wrong on IBM-AIX ? ------------------------------------------------------------------------ Ghostscript version (or include output from "gs -h"): Aladdin Ghostscript 8.53 (2005-10-20) ------------------------------------------------------------------------ Where you got Ghostscript: Artifex ------------------------------------------------------------------------ Operating system you are using: IBM AIX 5.1 IBM AIX 4.3
Please attach a sample file.
Created attachment 1989 [details] jpx.pdf Customer reports this doesn't work on IBM AIX
This error means jas_image_decode() didn't succeed. With jasper's error reporting, it's difficult to tell more without running in a debugger. The file displays fine in head under GNU/Linux built with gcc4. I can try compiling with the old gcc on linux, but really it would be better if someone with an AIX system could trace the failure inside jasper. (break at sjpx.c:291 and step in from there.) Can the customer try with a newer gcc? Does the problem occur with both gcc 2.95.3 and with xlc?
I've updated the jasper code in trunk to work around the stdbool problem with earlier gcc. Dan, you might also try a fresh checkout on AIX and see if that renders the file properly.
I am currently trying gs8.53. My AIX box is pretty sad. It has a 100 Mhz CPU. It takes a while to do a compile.
I was going to grab this file and try and run it through my system here (AIX5.2 with GCC 3.4.0) but this file is private and I can't download it to try... If you need me to give it a whirl... lemme know.
>If you need me to give it a whirl... lemme know. Thank you for the offer. However the test file was received under a non disclosure agreement so we cannot release it to you.
Created attachment 2076 [details] patch Add detection of non- GNU or C99 compatible malloc() to the configure scripts of Jasper and a work-aroing for malloc(0) to the code. DIFFERENCES: None The patch for the configure script is unnecessary large. Probably, the difference is caused by a different version of M4.
The IEEE 1003.1 spec, which is aligned with ISO C, states: If the size of the space requested is 0, the behavior is implementation-defined: the value returned shall be either a null pointer or a unique pointer. http://www.opengroup.org/onlinepubs/009695399/functions/malloc.html In any case, I think malloc's of 0 should be removed from the code, as it definitely creates spurious warnings while doing memory debugging, at the very least.
Created attachment 2216 [details] simplified patch This is a simplified version of the same patch. malloc(0) happens when libjasper reads optional tags in the embedded ICC profile. This doesn't happen too frequently and we can afford to allocate a few extra bytes. The checks for GNU-compatible malloc, proposed earlier, are not needed.
FWIW, there is an unresolved AIX-specific optimization bug (which goes away as soon as debug is switched on, and hence hasn't been resolved so far) at bug 688260. It does affect pdfwrite output, so it may be related.
The last patch was committed as a rev. 8039.