|
From: Maxim O. <max...@gm...> - 2006-12-06 16:42:50
|
Hi All! I'm getting a error with 3.2.1 version (all tools, including just "valgrind --help"): --421:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --421:1:launcher tool 'memcheck' requested --421:1:launcher selected platform 'x86-linux' --421:1:launcher launching /tmp/vg-3.2.1/lib/valgrind/x86-linux/memcheck --421:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --421:1:main Welcome to Valgrind version 3.2.1 debug logging --421:1:main Checking current stack is plausible --421:1:main Checking initial stack was noted --421:1:main Starting the address space manager --421:1:main Address space manager is running --421: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. Looks like similar was already fixed before... any hints for debugging? Kind regards, Maxim |
|
From: Julian S. <js...@ac...> - 2006-12-06 17:00:26
|
Possibly you have some kind non-standard kernel? > Valgrind's memory management: out of memory: > newSuperblock's request for 1048576 bytes failed. > 4294967296 bytes have already been allocated. > Valgrind cannot continue. Sorry. Please send the results of a run with flags '-d -d'. J |
|
From: Maxim O. <max...@gm...> - 2006-12-06 17:18:52
|
True, this is a custom kernel, and UML. So appreciate any debugging hints. Detailed output is: --402:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --402:1:launcher tool 'memcheck' requested --402:1:launcher selected platform 'x86-linux' --402:1:launcher launching /tmp/vg-3.2.1/lib/valgrind/x86-linux/memcheck --402:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --402:1:main Welcome to Valgrind version 3.2.1 debug logging --402:1:main Checking current stack is plausible --402:1:main Checking initial stack was noted --402:1:main Starting the address space manager --402:2:aspacem sp_at_startup = 0x00BFFADB50 (supplied) --402:2:aspacem minAddr = 0x0004000000 (computed) --402:2:aspacem maxAddr = 0x00BFFACFFF (computed) --402:2:aspacem cStart = 0x0004000000 (computed) --402:2:aspacem vStart = 0x0061FD7000 (computed) --402:2:aspacem suggested_clstack_top = 0x00BEFADFFF (computed) --402:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --402:2:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --402:2:aspacem 1: 0004000000-0061FD6FFF 1503m --402:2:aspacem 2: RSVN 0061FD7000-0061FD7FFF 4096 ----- SmFixed --402:2:aspacem 3: 0061FD8000-00BFFACFFF 1503m --402:2:aspacem 4: RSVN 00BFFAD000-00FFFFFFFF 1024m ----- SmFixed --402:2:aspacem >>> --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 >>> --402:1:main Address space manager is running --402: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. On 12/6/06, Julian Seward <js...@ac...> wrote: > > Possibly you have some kind non-standard kernel? > > > Valgrind's memory management: out of memory: > > newSuperblock's request for 1048576 bytes failed. > > 4294967296 bytes have already been allocated. > > Valgrind cannot continue. Sorry. > > Please send the results of a run with flags '-d -d'. > > J > |
|
From: Igmar P. <mai...@jd...> - 2006-12-07 08:59:05
|
> --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 ? Igmar |
|
From: Maxim O. <max...@gm...> - 2006-12-07 09:55:12
|
It gives: # cat /proc/self/maps 08048000-0804c000 r-xp 00000000 62:00 17 /bin/cat 0804c000-0804d000 rw-p 00003000 62:00 17 /bin/cat 0804d000-0806e000 rw-p 0804d000 00:00 0 [heap] 40000000-40015000 r-xp 00000000 62:00 3667 /lib/ld-2.3.3.so 40016000-40017000 r--p 00015000 62:00 3667 /lib/ld-2.3.3.so 40017000-40018000 rw-p 00016000 62:00 3667 /lib/ld-2.3.3.so 40018000-40120000 r-xp 00000000 62:00 3676 /lib/libc-2.3.3.so 40120000-40126000 r--p 00107000 62:00 3676 /lib/libc-2.3.3.so 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] 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 ? > > > > Igmar > |
|
From: Julian S. <js...@ac...> - 2006-12-07 11:57:20
|
> 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. J |
|
From: Maxim O. <max...@gm...> - 2006-12-07 17:30:15
|
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 |
|
From: Julian S. <js...@ac...> - 2006-12-07 17:37:06
|
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 |
|
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
>
|
|
From: Julian S. <js...@ac...> - 2006-12-25 21:41:55
|
This looks like in fact it is the same problem as bug report http://bugs.kde.org/show_bug.cgi?id=132998 J On Monday 11 December 2006 13:43, Maxim Osipov wrote: > 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 > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Maxim O. <max...@si...> - 2006-12-26 05:29:46
|
Yes. The environment is exactly the same ;) Maxim Julian Seward wrote: > This looks like in fact it is the same problem as bug report > http://bugs.kde.org/show_bug.cgi?id=132998 > > J > > On Monday 11 December 2006 13:43, Maxim Osipov wrote: >> 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 >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Maxim Osipov OOO Siemens, CT, Embedded Linux Tel.: +7 (812) 324 8379 |
|
From: Julian S. <js...@ac...> - 2006-12-26 17:40:15
|
Maxim
> >> 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:
I would like to fix this, and it is probably easy to fix, but I don't
have a way to test the fix. Your fix is nearly right but it is not
general enough.
Could you try a vanilla 3.2.1 + the following diff, and tell me if it
works? Both with and without --sanity-level=3 ?
J
Index: coregrind/m_aspacemgr/aspacemgr.c
===================================================================
--- coregrind/m_aspacemgr/aspacemgr.c (revision 6427)
+++ coregrind/m_aspacemgr/aspacemgr.c (working copy)
@@ -3411,9 +3411,10 @@
if (record_gap && gapStart < start)
(*record_gap) ( gapStart, start-gapStart );
- (*record_mapping) ( start, endPlusOne-start,
- prot, dev, ino,
- foffset, filename );
+ if (record_mapping && start < endPlusOne)
+ (*record_mapping) ( start, endPlusOne-start,
+ prot, dev, ino,
+ foffset, filename );
if ('\0' != tmp) {
filename[i_eol - i] = tmp;
|