GPL Ghostscript SVN PRE-RELEASE 8.72 (2010-02-11)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
[New Thread 0x2b30420c4000 (LWP 11588)]

Program received signal SIGSEGV, Segmentation fault.
0x00002b3040f7b5cd in names_trace_finish () from /usr/lib64/libgs.so.8
(gdb) bt
#0  0x00002b3040f7b5cd in names_trace_finish () from /usr/lib64/libgs.so.8
#1  0x00002b3040f7982d in gs_gc_reclaim () from /usr/lib64/libgs.so.8
#2  0x00002b30410085b4 in context_reclaim () from /usr/lib64/libgs.so.8
#3  0x00002b3040f49045 in ireclaim () from /usr/lib64/libgs.so.8
#4  0x00002b3040f44bf1 in interp_reclaim () from /usr/lib64/libgs.so.8
#5  0x00002b3040f46704 in gs_interpret () from /usr/lib64/libgs.so.8
#6  0x00002b3040f3ba4e in gs_main_run_string_end () from /usr/lib64/libgs.so.8
#7  0x00002b3040f3ca50 in run_string () from /usr/lib64/libgs.so.8
#8  0x00002b3040f3d1b4 in runarg () from /usr/lib64/libgs.so.8
#9  0x00002b3040f3d368 in argproc () from /usr/lib64/libgs.so.8
#10 0x00002b3040f3ea5b in gs_main_init_with_args () from /usr/lib64/libgs.so.8
#11 0x0000000000400a01 in main (argc=8, argv=0x7ffff5388fe8)
    at ./psi/dxmainc.c:84
(gdb)

Created attachment 6364 [details]
test attachment

This ran fine on win32.  Jason mentioned on IRC he is running 64bit.

I had a quick look at this (in the hope it was the same as a crash I was seeing).

On 64 bit linux, I don't get a crash, but valgrind reports an invalid read and invalid write in names_trace_finish() (iname.c:427).

The problem appears to be that name_scan_sub() (at line 419) frees the subtable "names" and "strings" memory, and then at line 426 and 427, o_set_unmarked() reads then writes to the memory headers we've just freed.

Removing the code (lines 424-428 inclusive):
	    if (nt->sub[i].names == 0 && gcst != 0) {
		/* Mark the just-freed sub-table as unmarked. */
		o_set_unmarked((obj_header_t *)sub - 1);
		o_set_unmarked((obj_header_t *)ssub - 1);
	    }

Causes the valgrind warning to go away, and doesn't /seem/ to cause a memory leak (I haven't checked exhaustively!). But this is a bit beyond my ken just now.

It seems quite possible that a different configuration/OS etc could cause the memory we've freed in name_scan_sub() to be the segment that triggers the OS to resize the heap, thus accessing the memory would cause a segmentation fault, or equivalent.

This bug looks suspiciously like the description of bug 690129 which Igor
attempted to address with rev 9179. Maybe that fix wasn't enough ?

This will take some digging into the name table handling and why we need to
unmark the entries -- an area I haven't dug into before.

Chris, if you have time to dig into it, great !!!

Created attachment 6522 [details]
path for iname.c


The reason the memory in question needs to be explicitly unmarked is because gs_free_object() may not actually free it. If the memory is allocated from a chunk in previous save level, gs_free_object() will not return it to the free list (or to the OS). But the memory reference is explicitly removed from the current save level, so clearing the gc marks may not happen as we'd expect, thus *possibly* leaving spuriously already marked memory around to confuse the next gc phase.

A small rearrangement of the code (see patch attachment) dispenses with the valgrind warning, but keeps the "firewall" of unmarking the potentially freed memory.

patch committed in r11610.

As we could not reproduce the crash, reassigning to Jason in hope he can confirm the crash was the same problem valgrind reported.

*** Bug 691005 has been marked as a duplicate of this bug. ***

I can't reproduce this in the current HEAD 9.00

(In reply to comment #10)
> I can't reproduce this in the current HEAD 9.00

Thanks for testing it.