Bug 568554

Created attachment 396435 [details]
File: backtrace

8.71 doesn't seem to be affected by this due to this commit (r10252):

    Consider '0000000000 00000 n' as a free entry, issue a warning, and continue
    processing xref table. Files with this error, generated by Quartz PDFContext
    are getting increasingly common. Bug 690873.
    
    DIFFERENCES:
    None.

However I don't think it addresses the issue we're seeing here.  After reverting that change in ghostscript SVN HEAD I see this from running it under valgrind:

==27370== Invalid read of size 4
==27370==    at 0x4B810A: names_trace_finish (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4B6231: gs_gc_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x5303E3: context_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x485741: ireclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4811AE: interp_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4825A2: interp (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x48323A: gs_interpret (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x478014: gs_main_run_string_end (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x47907D: run_string (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4797CD: runarg (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x47B14B: gs_main_init_with_args (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x408B40: main (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==  Address 0x559fdc8 is 72 bytes inside a block of size 8,280 free'd
==27370==    at 0x4A04D72: free (vg_replace_malloc.c:325)
==27370==    by 0x6D116F: alloc_free_chunk (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x6D1BEF: i_free_object (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4B7E8A: name_free_sub (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4B7FB9: name_scan_sub (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4B80EE: names_trace_finish (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4B6231: gs_gc_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x5303E3: context_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x485741: ireclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4811AE: interp_reclaim (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x4825A2: interp (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)
==27370==    by 0x48323A: gs_interpret (in /home/twaugh/devel/git-svn/trunk-only/ghostscript/bin/gs)

So we're trying to read from memory we've previously freed.  That could possibly lead to a segfault later on, depending on what that value is used for -- I'm not seeing a crash here on x86_64.

Here it is from ghostscript-8.71-7.fc13 with the no-free-entry patch reverted, this time with line numbers:

==27002== Invalid read of size 4
==27002==    at 0x4D9596A: names_trace_finish (iname.c:424)
==27002==    by 0x4D933A1: gs_gc_reclaim (igc.c:370)
==27002==    by 0x4E0977B: context_reclaim (zcontext.c:283)
==27002==    by 0x4D613B3: ireclaim (ireclaim.c:153)
==27002==    by 0x4D5CE90: interp_reclaim (interp.c:427)
==27002==    by 0x4D5E21B: interp (interp.c:1690)
==27002==    by 0x4D5EDCA: gs_interpret (interp.c:496)
==27002==    by 0x4D536D4: gs_main_run_string_end (imain.c:214)
==27002==    by 0x4D548ED: run_string (imainarg.c:814)
==27002==    by 0x4D55109: runarg (imainarg.c:805)
==27002==    by 0x4D56AAB: gs_main_init_with_args (imainarg.c:215)
==27002==    by 0x400A33: main (dxmainc.c:84)
==27002==  Address 0x70c0d78 is 72 bytes inside a block of size 8,280 free'd
==27002==    at 0x4A04D72: free (vg_replace_malloc.c:325)
==27002==    by 0x4F772A9: alloc_free_chunk (gsalloc.c:1831)
==27002==    by 0x4F77D5F: i_free_object (gsalloc.c:820)
==27002==    by 0x4D956EC: name_free_sub (iname.c:540)
==27002==    by 0x4D95819: name_scan_sub (iname.c:582)
==27002==    by 0x4D9594E: names_trace_finish (iname.c:416)
==27002==    by 0x4D933A1: gs_gc_reclaim (igc.c:370)
==27002==    by 0x4E0977B: context_reclaim (zcontext.c:283)
==27002==    by 0x4D613B3: ireclaim (ireclaim.c:153)
==27002==    by 0x4D5CE90: interp_reclaim (interp.c:427)
==27002==    by 0x4D5E21B: interp (interp.c:1690)
==27002==    by 0x4D5EDCA: gs_interpret (interp.c:496)

This corresponds with:

freed ==>   name_scan_sub(nt, i, true);
            if (save_count != nt->sub_count) {
                /* name_scan_sub has released the i-th entry. */
                continue;
            }
            if (nt->sub[i].names == 0 && gcst != 0) {
                /* Mark the just-freed sub-table as unmarked. */
                o_set_unmarked((obj_header_t *)sub - 1);
read ==>        o_set_unmarked((obj_header_t *)ssub - 1);
            }

Not positive it's in the same call.

*** This bug has been marked as a duplicate of bug 465311 ***