|
From: Dennis L. <pla...@gm...> - 2004-06-17 22:23:39
|
Hi, especially for debugging a Program under few memory conditions, I have tried to run a program with ulimit -v 180000 set. Even with ls it does not work : # valgrind --tool=memcheck ls Segmentation Fault without the ulimit set, everything works fine. I have a P4 with 512MB RAM running Linux 2.6.6 with glibc 2.3.3 with NPTL enabled and running HEAD from a few days ago (todays HEAD does not compile). same bahaviour with latest release greets Dennis Carpe quod tibi datum est |
|
From: Nicholas N. <nj...@ca...> - 2004-06-18 11:46:55
|
On Fri, 18 Jun 2004, Dennis Lubert wrote: > especially for debugging a Program under few memory conditions, I have > tried to run a program with > ulimit -v 180000 > set. Even with ls it does not work : > # valgrind --tool=memcheck ls > Segmentation Fault > > without the ulimit set, everything works fine. > > I have a P4 with 512MB RAM running Linux 2.6.6 with glibc 2.3.3 with NPTL > enabled and running HEAD from a few days ago Thanks for the report, but this is unlikely to change; Valgrind needs a fair bit of memory to run, it's pretty unavoidable. > (todays HEAD does not compile). Can you post the 'make' output? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 09:03:56
|
On Sun, 20 Jun 2004, Dennis Lubert wrote: > >Thanks for the report, but this is unlikely to change; Valgrind needs a > >fair bit of memory to run, it's pretty unavoidable. > > But how much ? I have a System with 512MB Memory and 900MB swap. Even when > I set the ulimit to 1000MB it segfaults. Even when I set it to whatever I > have in memory it segfaults. > When Valgrind is running a test app, it needs ~120-140MB of memory, but not > even the 180MB I set the ulimit to.... Valgrind uses pretty much all of the address space; roughly, it places the client at low, typical addresses, and itself at high addresses. There is good reason for this -- separating the client and Valgrind protects Valgrind against wild client writes that might clobber Valgrind's memory. There are some problems with the memory layout being too inflexible (eg. see http://bugs.kde.org/show_bug.cgi?id=82301) but I think supporting ulimit'd processes is a non-goal. N |