|
From: Tom H. <to...@co...> - 2006-10-20 10:08:33
|
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/
|