abrt 1.0.7 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: gs -dNODISPLAY -dQUIET -sPDFname=microsoft-online-services-global-criminal-compliance-handbook.pdf -sDSCname=/tmp/gv_microsoft-online-ser.pdf.Gzjer7 pdf2dsc.ps -c quit comment: Reproduces 100%. I installed the debuginfo packages after the first crash, then tried again, and got another crash. I hope that the debuginfo information is included in the backtrace above. If not, let me know how to regenerate with debuginfo symbol information and I'll be happy to do that. component: ghostscript executable: /usr/bin/gs kernel: 2.6.31.6-166.fc12.x86_64 package: ghostscript-8.70-5.fc12 rating: 4 reason: Process /usr/bin/gs was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine) How to reproduce ----- 1. Open the following document in gv: http://www.wired.com/images_blogs/threatlevel/2010/02/microsoft-online-services-global-criminal-compliance-handbook.pdf
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 ***