After implementing a pointer stability validation in the garbager, got hundreds of error messages running any document. Note : the check is currently disabled with IGC_PTR_STABILITY_CHECK 0 in gxobj.h . related to the bug 688226.
Created attachment 1716 [details] stderr.txt Attaching errors obtained with running "-r72 -dBATCH comparefiles\001-01.ps" with display device - 883 messages total.
See also zmisc2.c ln 256.
Much of the "bedlam" seems to be a result of the "bedlam" detector. The space_id is only initialized in alloc_obj() but objects can be returned from the allocator in other ways (lifo, freelist) leaving this space id member uninitialized then it can be erroneously reported on the list. The code has to be properly instrumented before going through the error list.
There are currently many entries with the graphics state for example: GPL Ghostscript SVN PRE-RELEASE 8.71: ./psi/ilocate.c(521): Reference to a less stable object 0xa629ff4<gs_cie_render> in the space 'local' from 0xa72baa4<gs_state> in the space 'global' ! I am not going to look at these unless somebody knows why analysis is necessary. Adobe postscript does not treat the graphics state as an object in vm, we allocate it in global vm and have elaborate memory management exceptions to handle the gstate which I assume deal with the local references of the gstate, drilling down into the that will be saved for a real bug. I did check the following works (doesn't create a dangling reference): save % make a color space in local vm [ /CIEBasedABC << /RangeABC [0.0 0.9505 0.0 1.0 0.0 1.0890] /RangeLMN [0.0 0.9505 0.0 1.0 0.0 1.0890] /WhitePoint [0.9505 1.0 1.0890] >> ] setcolorspace % get rid of local vm. restore currentcolorspace % pststack gives devicegray, the start up color space
We probably should run the code with IGC_PTR_STABILITY_CHECK to see that we don't have memory problems, but I doubt the problems in this report (now 7 years old) are relevant any longer.