[Valgrind-users] Crash when running valgrind

[Phil L. <plo...@sa...>]

When I run helgrind on an image which hasn't been stripped, I'm getting the following crash:

==12878== Helgrind, a thread error detector
==12878== Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al.
==12878== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info

--12878-- Valgrind library directory: /usr/local/lib/valgrind
--12878-- Reading syms from /libexec/ld-elf.so.1
--12878--    object doesn't have a symbol table
--12878-- Reading syms from /d2/local/sandvine/ptsd/ptsd
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0xa outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0xb .. 0x76 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0x47 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x0 .. 0x0 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x1 .. 0x3 outside mapped rw segments (NONE)
--12878-- warning: DiCfSI 0x4 .. 0x47 outside mapped rw segments (NONE)
--12878-- Reading syms from /d2/local/lib/valgrind/helgrind-amd64-freebsd
--12878--    object doesn't have a symbol table
--12878--    object doesn't have a dynamic symbol table
--12878-- Scheduler: using generic scheduler lock implementation.

valgrind: m_main.c:2180 (valgrind_main): Assertion 'seg' failed.
==12878==    at 0x3801E1E7: ??? (in /d2/local/lib/valgrind/helgrind-amd64-freebsd)

sched status:
  running_tid=1

Thread 1: status = VgTs_Init
==12878==    at 0x0: ???


   //--------------------------------------------------------------
   // Tell the tool about the initial client memory permissions
   //   p: aspacem
   //   p: mallocfree
   //   p: setup_client_stack
   //   p: setup_client_dataseg
   //
   // For each segment we tell the client about, look up in
   // addr2dihandle as created above, to see if there's a debuginfo
   // handle associated with the segment, that we can hand along
   // to the tool, to be helpful.
   //--------------------------------------------------------------
   VG_(debugLog)(1, "main", "Tell tool about initial permissions\n");
   { Addr*     seg_starts;
     Int       n_seg_starts;

     tl_assert(addr2dihandle);

     /* Mark the main thread as running while we tell the tool about
        the client memory so that the tool can associate that memory
        with the main thread. */
     tl_assert(VG_(running_tid) == VG_INVALID_THREADID);
     VG_(running_tid) = tid_main;

     seg_starts = VG_(get_segment_starts)( &n_seg_starts );
     vg_assert(seg_starts && n_seg_starts >= 0);

     /* show interesting ones to the tool */
     for (i = 0; i < n_seg_starts; i++) {
        Word j, n;
        NSegment const* seg
           = VG_(am_find_nsegment)( seg_starts[i] );
---->        vg_assert(seg);
        if (seg->kind == SkFileC || seg->kind == SkAnonC) {
          /* This next assertion is tricky.  If it is placed
             immediately before this 'if', it very occasionally fails.
             Why?  Because previous iterations of the loop may have
             caused tools (via the new_mem_startup calls) to do
             dynamic memory allocation, and that may affect the mapped
             segments; in particular it may cause segment merging to
             happen.  Hence we cannot assume that seg_starts[i], which
             reflects the state of the world before we started this
             loop, is the same as seg->start, as the latter reflects
             the state of the world (viz, mappings) at this particular
             iteration of the loop.

What is this complaining about?

Phil