Summary: | allocation of profile default_gray.icc handle failed, core dump | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Greg Wooledge <wooledg> |
Component: | Build Process | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chris.liddell, wooledg |
Priority: | P4 | ||
Version: | 9.04 | ||
Hardware: | HP | ||
OS: | HP-UX | ||
Customer: | Word Size: | --- |
Description
Greg Wooledge
2011-10-10 19:04:44 UTC
Actually gdb is working, but gs was compiled without -g. I removed some obj/*.o files and manually built them with -g, and tracked the problem down to here: cmsOpenProfileFromMem (MemPtr=0x40a44170, dwSize=416) at lcms/src/cmsio1.c:2599 2599 NewIcc = _cmsCreateProfileFromMemPlaceholder(MemPtr, dwSize); (gdb) n 2600 if (!NewIcc) return NULL; (gdb) n 2602 if (!ReadHeader(NewIcc, TRUE)) return NULL; (gdb) print NewIcc $1 = (LPLCMSICCPROFILE) 0x40a44518 (gdb) n 2608 } _cmsCreateProfileFromMemPlaceholder returns what I assume is a valid pointer, but ReadHeader fails. Restarting with a breakpoint on ReadHeader, we get: 289 if (Header.magic != icMagicNumber) goto ErrorCleanup; (gdb) n 356 Icc ->Close(Icc); I won't even try to guess why the comparison failed. This could be problematic to reproduce and debug since we don't have easy access to an HP-UX machine. The problem *might* be related to the issue with finding ICC profiles in this bug: http://bugs.ghostscript.com/show_bug.cgi?id=692532 Although, obviously, the crash is in a different place. The patch for gs_lev2.ps from the above bug just might help. Oh, based on Greg's second comment, ignore above. Greg, the second thing that springs to mind is are we getting the endianness right for the hardware? The machine is big endian. I'm not sure how the Ghostscript code is checking it, but if I step through the code, it appears to be applying the little endian transformation: Breakpoint 1, ReadHeader (Icc=0x40a44518, lIsFromMemory=1) at lcms/src/cmsio1.c:271 271 if (Icc -> Read(&Header, sizeof(icHeader), 1, Icc) != 1) (gdb) n 276 AdjustEndianess32((LPBYTE) &Header.size); (gdb) step AdjustEndianess32 (pByte=0x7a0027dc "") at lcms/src/cmsio1.c:104 104 temp1 = *pByte++; So yes, it appears to think the machine is the wrong endianness. It looks like lcms.h has some stuff to detect big endian systems, but maybe HP-UX defeats it. Could you perhaps try (after a "make clean debugclean"): CC="gcc -DUSE_BIG_ENDIAN=1" ./configure Then build, and test. If that works, I'll reassign the bug to me as a build problem. Thanks. Success. I was able to run it and see the tiger from the examples directory. Thanks. :) Great, thanks for trying it. Reassigning to me as a build issue: lcms doesn't get the Ghostscript endian setting. Not usually a problem as lcms.h has code to spot SPARC and PPC builds, but (clearly!) not HP UX/PA-RISC. |