Re: [Valgrind-users] valgrind stack problem

[Tom H. <to...@co...>]

In message <116...@im...>
        Paul Floyd <pa...@fr...> wrote:

> I just noticed another thing. If I use --sanity-check=3 I get
>
> # --30200:0:aspacem  sync_check_mapping_callback: segment mismatch: V's seg:
> # --30200:0:aspacem  NSegment{file, start=0x8048000, end=0x9A40FFF,
> smode=SmFixed, dev=65043, ino=2147487009, offset=0, fnIdx=1, hasR=1, hasW=0,
> hasX=1, hasT=0, mark=0, name="/view/PFView/vobs/adms/ixl-dbg/sim/aut"}
> # --30200:0:aspacem  sync_check_mapping_callback: segment mismatch: kernel's
> seg:
> # --30200:0:aspacem  start=0x8048000 end=0x9A40FFF prot=5 dev=63 ino=12330004
> offset=0
> name="/ccstores/viewstore_1/admsviews/pfloyd/PFView.vws/.s/00011/80000d2144ec700aaut"
> # --30200:0:aspacem  sync check at m_aspacemgr/aspacemgr.c:2031
> (vgPlain_am_get_advisory): FAILED
> # --30200:0:aspacem
> # --30200:0:aspacem  Valgrind: FATAL: aspacem assertion failed:
> # --30200:0:aspacem    VG_(am_do_sync_check)
> (__PRETTY_FUNCTION__,__FILE__,__LINE__)
> # --30200:0:aspacem    at m_aspacemgr/aspacemgr.c:2031 (vgPlain_am_get_advisory)
> # --30200:0:aspacem  Exiting now.
>
> Could this be related? It looks like this is due to the fact that I'm running
> the test within ClearCase. No problem either here with valgrind 3.0.1.

I think this is a separate issue. It indicates that valgrind's record
of the memory map does not match the kernel's record for some reason.

The problem here is the device and inode numbers, which probably
aren't the most critical bits, but it is odd that they don't match.

The kernel has the mapping as device 63 and inode 12330004 which
equates to:

  /ccstores/viewstore_1/admsviews/pfloyd/PFView.vws/.s/00011/80000d2144ec700aaut

and valgrind as it as device 65043 and inode 2147487009 which equates
to:

  /view/PFView/vobs/adms/ixl-dbg/sim/aut

So valgrind has it as a mapping from the ClearCase virtual file system
thing (from what I've heard of CC - I have no experience of it) while
the kernel view is perhaps of the real underlying file? Is /ccstores a
real physical path on disk?

It would be interesting if you could start a program (I assume aut is
the program you are tracing?) from the CC view and then cat /proc/pid/maps
for it and see what path is reported...

Tom

-- 
Tom Hughes (to...@co...)
http://www.compton.nu/