Valgrind reports many warnings about uninitialized d.o.f.m.smark fields during GC in most PDF files and some PS files. For instance /home/regression/comparefiles/014-01.ps ==1147== Conditional jump or move depends on uninitialised value(s) ==1147== at 0x813C2C6: ptr_struct_mark (igc.c:1067) ==1147== by 0x813BBAA: gc_trace (igc.c:857) ==1147== by 0x813A1D6: gs_gc_reclaim (igc.c:326) ==1147== by 0x81CBE11: context_reclaim (zcontext.c:283) ==1147== by 0x80F70BD: gs_vmreclaim (ireclaim.c:153) ==1147== by 0x80F6E9C: ireclaim (ireclaim.c:75) ==1147== by 0x80F092F: interp_reclaim (interp.c:427) ==1147== by 0x80F3EC1: interp (interp.c:1686) ==1147== by 0x80F0B27: gs_call_interp (interp.c:496) ==1147== by 0x80F09BB: gs_interpret (interp.c:454) ==1147== by 0x80E5857: gs_main_interpret (imain.c:214) ==1147== by 0x80E6301: gs_main_run_string_end (imain.c:526) This warning indicates that smark field of some objects was not cleared but the mark phase accessed them anyway. All these warnings disappear when I_FORCE_GLOBAL_GC is set to true. Unfortunately, I'm dob't know GC well enough to suggest a patch. If we can eliminate these warnings, Ghostscript will be mostly free of Valgrind warnings, at least, on nullpage device.
*** Bug 688876 has been marked as a duplicate of this bug. ***
Please close this bug if it is no longer relevant, otherwise, please assign to Ralph.Giles
comments in 690506 indicate this is still open: The 3 messages about gc_trace_chunk() happen in most files. This issue is tracked as a bug 690176. All these warnings disappear when I_FORCE_GLOBAL_GC is set to true in igc.c . The error itself appears to be harmless and I usually run Valgrind with forced global GC to reduce the noise. Assigning to Ralph.
I am just starting to look at this one, Alex thinks it has been lingering too long and I agree. /usr/local/bin/valgrind --track-origins=yes --db-attach=yes ./gs -ZA -sOutputFile=/dev/null 014-01.ps ==10270== Conditional jump or move depends on uninitialised value(s) ==10270== at 0x8141E29: ptr_struct_mark (igc.c:1067) ==10270== by 0x81416EC: gc_trace (igc.c:857) ==10270== by 0x8140062: gs_gc_reclaim (igc.c:326) ==10270== by 0x81D919B: context_reclaim (zcontext.c:283) ==10270== by 0x80F99EA: gs_vmreclaim (ireclaim.c:153) ==10270== by 0x80F97D1: ireclaim (ireclaim.c:75) ==10270== by 0x80F2921: interp_reclaim (interp.c:427) ==10270== by 0x80F665C: interp (interp.c:1690) ==10270== by 0x80F2B37: gs_call_interp (interp.c:496) ==10270== by 0x80F29B1: gs_interpret (interp.c:454) ==10270== by 0x80E6B96: gs_main_interpret (imain.c:214) ==10270== by 0x80E7737: gs_main_run_string_end (imain.c:526) ==10270== Uninitialised value was created by a heap allocation ==10270== at 0x4024C1C: malloc (vg_replace_malloc.c:195) ==10270== by 0x843A3FD: gs_heap_alloc_bytes (gsmalloc.c:179) ==10270== by 0x8414BEF: alloc_acquire_chunk (gsalloc.c:1672) ==10270== by 0x841337B: i_alloc_string (gsalloc.c:903) ==10270== by 0x811C0F2: zstring (zstring.c:60) ==10270== by 0x80F24BC: call_operator (interp.c:111) ==10270== by 0x80F514A: interp (interp.c:1277) ==10270== by 0x80F2B37: gs_call_interp (interp.c:496) ==10270== by 0x80F29B1: gs_interpret (interp.c:454) ==10270== by 0x80E6B96: gs_main_interpret (imain.c:214) ==10270== by 0x80E7737: gs_main_run_string_end (imain.c:526) ==10270== by 0x80E760C: gs_main_run_string_with_length (imain.c:484) ==10270== ==10270== ==10270== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y 0x08141e29 in ptr_struct_mark (pep=0xbeaa1e2c, ignored=0xbeaa2410) at ./psi/igc.c:1067 1067 if (!o_is_unmarked(ptr)) (gdb) p ptr + 1 $3 = (obj_header_t *) 0x4ee6570 searching back through -ZA output this allocation was made in global vm, here's the entry: [a8:+< ]gs_makefont gs_font_type1(816) = 0x4ee6570 and the object header confirms this: p *ptr.d.o.t.type $8 = {ssize = 816, sname = 0x84c8614 "gs_font_type1", shared = 0x0, clear_marks = 0, enum_ptrs = 0x843dbde <basic_enum_ptrs>, reloc_ptrs = 0x843dd99 <basic_reloc_ptrs>, finalize = 0x8428c35 <gs_font_finalize>, proc_data = 0x84c8608} (gdb) Here we are doing a local garbage collection (gs_gc_reclaim's parameter global == 0) and we are trying to mark an object in an uncollected space (global vm). Alex's fix to clear marks in all spaces, not only collected spaces, would work here but note if this object were a reference and not a structure there would not be an issue. There is a gaurd in gc_trace() if (r_space(rptr) < min_trace) { ... } that would prevent ptr_struct_mark() from even being called. Alex do you have any insight into this? Why isn't the space checked for anything other than refs?
Being stuck as noted at the end of comment #4, I've asked Peter to have a look.
I think this might be the same issue as Bug 690915. Has there been any more progress on this bug?
Recent valgrind versions don't throw up this error. This is almost certainly a false positive due to earlier valgrind versions not fully understanding bit fields.