|
From: Art H. <ah...@ai...> - 2004-01-22 17:12:26
|
Hi. I'm building from CVS HEAD. The last valgrind to work on my machine was one built around a month ago or so, and since then all my builds complete but valgrind fails to run. A perusal of the valgrind mailing lists didn't show anyone posting a message demonstrating the same problem as I'm seeing so I'm writing in looking for help. I found the location of the error message (coregrind/ume.c) valgrind prints out and uncommented out a printf() call to see what it was doing; that's the stuff about elfbkr, b, and delta ... $ valgrind ls -l elfbrk=0xb80ed9a0 b=0x80f4000 delta=268435456 sbrk failed while adjusting brk base: perhaps we hit the datasize ulimit? failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited My machine has 128M of memory, which has not been a problem before. I'm currently running the 2.6.2-rc1 kernel, and have been running 2.6.X kernels for months. My libc is libc6-2.3.2-ds10 (I'm using Debian), and I'm compiling with Debian's latest gcc-3.3.3-pre compiler. Do I now need more memory in the machine for running valgrind? The ulimit info shows my datasize is unlimited. A kernel problem? Something else? Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 |
|
From: Jeremy F. <je...@go...> - 2004-01-22 21:57:51
|
On Thu, 2004-01-22 at 09:12, Art Haas wrote: > My machine has 128M of memory, which has not been a problem before. I'm > currently running the 2.6.2-rc1 kernel, and have been running 2.6.X > kernels for months. My libc is libc6-2.3.2-ds10 (I'm using Debian), and > I'm compiling with Debian's latest gcc-3.3.3-pre compiler. > > Do I now need more memory in the machine for running valgrind? The > ulimit info shows my datasize is unlimited. A kernel problem? Something > else? This doesn't actually mean you've run out of memory. What it's trying to do is extend the brk part of the address space up (*way* up), which allocates more virtual address space, but no physical memory. It could be because you've only got 128Mbytes, the kernel is complaining about the 256mbyte brk allocation. Try changing the value of "limit" to 64*1024*1024 at coregrind/ume.c:343. J |
|
From: Art H. <ah...@ai...> - 2004-01-23 00:20:16
|
On Thu, Jan 22, 2004 at 01:55:51PM -0800, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-22 at 09:12, Art Haas wrote: > > My machine has 128M of memory, which has not been a problem before. I'm > > currently running the 2.6.2-rc1 kernel, and have been running 2.6.X > > kernels for months. My libc is libc6-2.3.2-ds10 (I'm using Debian), and > > I'm compiling with Debian's latest gcc-3.3.3-pre compiler. > > > > Do I now need more memory in the machine for running valgrind? The > > ulimit info shows my datasize is unlimited. A kernel problem? Something > > else? > > This doesn't actually mean you've run out of memory. What it's trying > to do is extend the brk part of the address space up (*way* up), which > allocates more virtual address space, but no physical memory. It could > be because you've only got 128Mbytes, the kernel is complaining about > the 256mbyte brk allocation. Try changing the value of "limit" to > 64*1024*1024 at coregrind/ume.c:343. > Tried it (and 32*1024*1024 also), but the result ends up the same in that valgrind prints out the error message about sbrk failing. Lots of printing out of eflbrk, b, and delta though. Here's the output for the '32*1024*1024' build ... $ valgrind ls -l elfbrk=0xb80ed9a0 b=0x80f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0xa0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0xc0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0xe0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x100f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x120f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x140f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x160f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x180f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x1a0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x1c0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x1e0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x200f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x220f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x240f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x260f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x280f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x2a0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x2c0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x2e0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x300f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x320f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x340f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x360f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x380f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x3a0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x3c0f4000 delta=33554432 elfbrk=0xb80ed9a0 b=0x3e0f4000 delta=33554432 sbrk failed while adjusting brk base: perhaps we hit the datasize ulimit? failed to load /usr/local/lib/valgrind/stage2: Cannot allocate memory $ 'b' just gets bigger, but elfbrk and 'delta' stay the same. Anything else I can try? Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 |
|
From: Jeremy F. <je...@go...> - 2004-01-23 00:31:57
|
On Thu, 2004-01-22 at 16:20, Art Haas wrote:
> 'b' just gets bigger, but elfbrk and 'delta' stay the same. Anything else
> I can try?
Well, delta is just 32M, so I wouldn't expect it to change until the
very end. b will keep growing until it hits endbrk (it'll take a while
in 32M steps).
Ah! And that printf itself will cause the failure, because it maps some
memory. So, comment out the printf. If that doesn't work, try this as
well:
*** ume.c 6 Jan 2004 16:02:29 -0000 1.7
--- ume.c 23 Jan 2004 00:29:03 -0000
*************** ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
*** 352,357 ****
--- 352,358 ----
"perhaps we hit the datasize ulimit?\n");
return 0;
}
+ munmap((char *)PGROUNDUP(b), delta);
b += delta;
}
munmap(initb, (char *)PGROUNDDN(elfbrk)-initb);
But basically I consider this whole mucking about with brk a bug anyway,
so I intend changing the way all this works.
J
|
|
From: Art H. <ah...@ai...> - 2004-01-23 00:51:46
|
On Thu, Jan 22, 2004 at 04:29:56PM -0800, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-22 at 16:20, Art Haas wrote: > > 'b' just gets bigger, but elfbrk and 'delta' stay the same. Anything else > > I can try? > > Well, delta is just 32M, so I wouldn't expect it to change until the > very end. b will keep growing until it hits endbrk (it'll take a while > in 32M steps). > > Ah! And that printf itself will cause the failure, because it maps some > memory. So, comment out the printf. If that doesn't work, try this as > well: > *** ume.c 6 Jan 2004 16:02:29 -0000 1.7 > --- ume.c 23 Jan 2004 00:29:03 -0000 > *************** ESZ(Addr) mapelf(struct elfinfo *e, ESZ( > *** 352,357 **** > --- 352,358 ---- > "perhaps we hit the datasize ulimit?\n"); > return 0; > } > + munmap((char *)PGROUNDUP(b), delta); > b += delta; > } > munmap(initb, (char *)PGROUNDDN(elfbrk)-initb); I bumped the magic number back up to 64 and removed the print() call, and the message about sbrk failing went away, but valgrind did not run. Instead I got a long print out about the options - just what you see when you run 'valgrind --help'. Adding in the munmap() call didn't help either. I then tried explicitly adding in a '--tool' option ... $ valgrind --tool=memcheck ls -l Illegal instruction $ No luck again. For grins I then restored the number back to 256, and got the old error message again. > But basically I consider this whole mucking about with brk a bug anyway, > so I intend changing the way all this works. I'll keep building the CVS code and keep trying things out. If I can try out some more patches let me know. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 |
|
From: Jeremy F. <je...@go...> - 2004-01-23 02:22:53
|
On Thu, 2004-01-22 at 16:51, Art Haas wrote: > I then tried explicitly adding in a '--tool' option ... Yes, memcheck isn't the default any more. > $ valgrind --tool=memcheck ls -l > Illegal instruction Interesting! What does /proc/cpuinfo say? Is this an old 486 or 586 machine? J |
|
From: Art H. <ah...@ai...> - 2004-01-23 14:22:22
|
On Thu, Jan 22, 2004 at 06:20:50PM -0800, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-22 at 16:51, Art Haas wrote: > > I then tried explicitly adding in a '--tool' option ... > > Yes, memcheck isn't the default any more. > > > $ valgrind --tool=memcheck ls -l > > Illegal instruction > > Interesting! What does /proc/cpuinfo say? Is this an old 486 or 586 > machine? > Yes - Pentium 200 MHz - a dinosaur by today's standards. $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 4 model name : Pentium MMX stepping : 3 cpu MHz : 199.777 fdiv_bug : no hlt_bug : no f00f_bug : yes coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 mmx bogomips : 394.24 $ -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 |
|
From: Art H. <ah...@ai...> - 2004-01-24 16:20:25
|
Hi.
A CVS update from this morning (Jan 24) and rebuild now gives me a
working valgrind! I still have these changes in the ume.c file based on
the previous e-mail exchanges:
Index: coregrind/ume.c
===================================================================
RCS file: /home/kde/valgrind/coregrind/ume.c,v
retrieving revision 1.7
diff -u -u -r1.7 ume.c
--- coregrind/ume.c 6 Jan 2004 16:02:29 -0000 1.7
+++ coregrind/ume.c 24 Jan 2004 15:52:38 -0000
@@ -340,18 +340,19 @@
while(b < (char *)elfbrk) {
unsigned delta = (char *)elfbrk - b;
- static const unsigned limit = 256*1024*1024;
+ static const unsigned limit = 128*1024*1024;
char *bb;
if (delta > limit)
delta = limit;
- //printf("elfbrk=%p b=%p delta=%u\n", elfbrk, b, delta);
+ // printf("elfbrk=%p b=%p delta=%u\n", elfbrk, b, delta);
bb = sbrk(delta);
if (bb != b) {
fprintf(stderr, "sbrk failed while adjusting brk base: "
"perhaps we hit the datasize ulimit?\n");
return 0;
}
+ munmap((char *)PGROUNDUP(b), delta);
b += delta;
}
munmap(initb, (char *)PGROUNDDN(elfbrk)-initb);
The CPU capabilities tests fixed things up nicely here!
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
|
|
From: Tom H. <th...@cy...> - 2004-01-23 07:11:40
|
In message <200...@ar...>
"Art Haas" <ah...@ai...> wrote:
> I then tried explicitly adding in a '--tool' option ...
>
> $ valgrind --tool=memcheck ls -l
> Illegal instruction
> $
Was it an a machine with an old, pre SSE CPU? If so then this is the
bug I reported yesterday where valgrind now always thinks you have SSE
support and tries to save the SSE state.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|