|
From: Maxim O. <max...@gm...> - 2006-12-11 13:44:04
|
Hello!
I did some debugging and it looks like the problem is really with my
kernel. If we look at map of a process, the last line will be like
below:
cat /proc/self/maps
....
40126000-40128000 rw-p 0010d000 62:00 3676 /lib/libc-2.3.3.so
40128000-4012a000 rw-p 40128000 00:00 0
bfadb000-bfaf0000 rw-p bfadb000 00:00 0 [stack]
00000000-00000000 ---p 00000000 00:00 0 [vdso]
It produces a problem of too big segment, covering all available
memory. Quick and dirty fix (because I cannot change kernel now) was
like:
diff -Nuar valgrind-3.2.1/coregrind/m_aspacemgr/aspacemgr.c
valgrind-3.2.1.1/coregrind/m_aspacemgr/aspacemgr.c
--- valgrind-3.2.1/coregrind/m_aspacemgr/aspacemgr.c 2006-09-13
00:37:48.000000000 +0200
+++ valgrind-3.2.1.1/coregrind/m_aspacemgr/aspacemgr.c 2006-12-11
14:09:02.000000000 +0100
@@ -1300,7 +1300,7 @@
file, line, fn);
VG_(debugLog)(0,"aspacem", "\n");
-# if 0
+# if 1
{
HChar buf[100];
VG_(am_show_nsegments)(0,"post syncheck failure");
@@ -3411,16 +3411,20 @@
if (record_gap && gapStart < start)
(*record_gap) ( gapStart, start-gapStart );
- (*record_mapping) ( start, endPlusOne-start,
- prot, dev, ino,
- foffset, filename );
+ if ((start != 0) || (endPlusOne != 0)) {
+ (*record_mapping) ( start, endPlusOne-start,
+ prot, dev, ino,
+ foffset, filename );
+ }
if ('\0' != tmp) {
filename[i_eol - i] = tmp;
}
i = i_eol + 1;
- gapStart = endPlusOne;
+ if ((start != 0) || (endPlusOne != 0)) {
+ gapStart = endPlusOne;
+ }
}
if (record_gap && gapStart < Addr_MAX)
Yes, it is ugly :) But is it dangerous? Do you see any potential
problems with it?
Thanks!
Maxim
On 12/7/06, Julian Seward <js...@ac...> wrote:
>
> Ok, so parse_procselfmaps() is not doing anything for some reason.
> I suggest you figure out why not. It's pretty simple although coded
> a bit strangely due to extreme restrictions on what functions it is
> safe to call from m_aspacemgr.c. The function VG_(debugLog) is your
> friend here.
>
> J
>
> On Thursday 07 December 2006 17:30, Maxim Osipov wrote:
> > On 12/7/06, Julian Seward <js...@ac...> wrote:
> > > > On 12/7/06, Igmar Palsenberg <mai...@jd...> wrote:
> > > > > > --402:2:aspacem Reading /proc/self/maps
> > > > > > --402:2:aspacem <<< SHOW_SEGMENTS: With contents of
> > > > > > /proc/self/maps (1 segments, 1 segnames)
> > > > > > --402:2:aspacem 0: ANON 0000000000-00FFFFFFFF 0 -----
> > > > > > --402:2:aspacem >>>
> > > > >
> > > > > Strange, never seen this before. Does a cat /proc/self/maps in bash
> > > > > give the same ?
> > >
> > > I agree, this does not look correct. It would be useful to know what
> > > V's /proc/self/maps parser is seeing. In
> > > coregrind/m_aspacemgr/aspacemgr.c, fn parse_procselfmaps(), change if (0)
> > > to if (1) to find out, and send the results.
> >
> > Ok, output with detailed info below:
> >
> > --398:1:debuglog DebugLog system started by Stage 1, level 2 logging
> > requested --398:1:launcher tool 'memcheck' requested
> > --398:1:launcher selected platform 'x86-linux'
> > --398:1:launcher launching /opt/atcamg/lib/valgrind/x86-linux/memcheck
> > --398:1:debuglog DebugLog system started by Stage 2 (main), level 2
> > logging requested
> > --398:1:main Welcome to Valgrind version 3.2.1 debug logging
> > --398:1:main Checking current stack is plausible
> > --398:1:main Checking initial stack was noted
> > --398:1:main Starting the address space manager
> > --398:2:aspacem sp_at_startup = 0x00BF8110A0 (supplied)
> > --398:2:aspacem minAddr = 0x0004000000 (computed)
> > --398:2:aspacem maxAddr = 0x00BF810FFF (computed)
> > --398:2:aspacem cStart = 0x0004000000 (computed)
> > --398:2:aspacem vStart = 0x0061C09000 (computed)
> > --398:2:aspacem suggested_clstack_top = 0x00BE811FFF (computed)
> > --398:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0
> > segnames) --398:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m -----
> > SmFixed --398:2:aspacem 1: 0004000000-0061C08FFF 1500m
> > --398:2:aspacem 2: RSVN 0061C09000-0061C09FFF 4096 ----- SmFixed
> > --398:2:aspacem 3: 0061C0A000-00BF810FFF 1500m
> > --398:2:aspacem 4: RSVN 00BF811000-00FFFFFFFF 1031m ----- SmFixed
> > --398:2:aspacem >>>
> > --398:2:aspacem Reading /proc/self/maps
> > --398:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps
> > (1 segments, 1 segnames)
> > --398:2:aspacem 0: ANON 0000000000-00FFFFFFFF 0 -----
> > --398:2:aspacem >>>
> > --398:1:main Address space manager is running
> > --398:1:main Starting the dynamic memory manager
> >
> > Valgrind's memory management: out of memory:
> > newSuperblock's request for 1048576 bytes failed.
> > 4294967296 bytes have already been allocated.
> > Valgrind cannot continue. Sorry.
> >
> > Any ideas?
> >
> > Maxim
>
|