Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: An object management bug in ghostscript could cause it to attempt to read from uninitialized memory, occasionally leading to a segmentation fault. This has been fixed by back-porting a patch from a newer version.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -An object management bug in ghostscript could cause it to attempt to read from uninitialized memory, occasionally leading to a segmentation fault. This has been fixed by back-porting a patch from a newer version.+Due to an incorrect object management, Ghostscript may have attempted to read from uninitialized memory, which could have lead to a segmentation fault. This has been fixed by back-porting a patch from a newer version.
I could reproduce this bug with ghostscript-8.70-4.el5 # uname -a Linux x86-64-5c-m1.ss.eng.bos.redhat.com 2.6.18-194.17.1.el5xen #1 SMP Mon Sep 20 07:20:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa ghostscript ghostscript-8.70-4.el5.i386 ghostscript-8.70-4.el5.x86_64 # valgrind gs -dSAFER -dCompatibilityLevel=1.3 $OPTIONS -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite "-sOutputFile=C.pdf" -c .setpdfwrite -f Cappellari_Voronoi_Binning_Review.ps (snip) ==20158== Invalid read of size 4 ==20158== at 0x4DCD2AD: names_trace_finish (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4DCAE6C: gs_gc_reclaim (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4E43BC3: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D9AD2A: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D96780: interp_reclaim (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D9834F: gs_interpret (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D8D6ED: gs_main_run_string_end (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D8E6EF: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D8EE73: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D8F031: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D90690: gs_main_init_with_args (in /usr/lib64/libgs.so.8.70) ==20158== by 0x400A00: main (in /usr/bin/gs) ==20158== Address 0x7d7f848 is 72 bytes inside a block of size 8,280 free'd ==20158== at 0x4A05A31: free (vg_replace_malloc.c:325) ==20158== by 0x4FA1778: alloc_free_chunk (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4FA20FF: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4DCD052: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4DCD161: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4DCD28C: names_trace_finish (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4DCAE6C: gs_gc_reclaim (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4E43BC3: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D9AD2A: ??? (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D96780: interp_reclaim (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D9834F: gs_interpret (in /usr/lib64/libgs.so.8.70) ==20158== by 0x4D8D6ED: gs_main_run_string_end (in /usr/lib64/libgs.so.8.70) ==20158== ==20158== ==20158== HEAP SUMMARY: ==20158== in use at exit: 118,773 bytes in 3,954 blocks ==20158== total heap usage: 22,531 allocs, 18,577 frees, 71,640,405 bytes allocated ==20158== ==20158== LEAK SUMMARY: ==20158== definitely lost: 5,172 bytes in 37 blocks ==20158== indirectly lost: 43,928 bytes in 1,769 blocks ==20158== possibly lost: 0 bytes in 0 blocks ==20158== still reachable: 69,673 bytes in 2,148 blocks ==20158== suppressed: 0 bytes in 0 blocks ==20158== Rerun with --leak-check=full to see details of leaked memory ==20158== ==20158== For counts of detected and suppressed errors, rerun with: -v ==20158== Use --track-origins=yes to see where uninitialised values come from ==20158== ERROR SUMMARY: 883 errors from 6 contexts (suppressed: 27 from 11)
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0137.html