Version: 3.2.0 (using KDE KDE 3.5.4) Compiler: gcc 3.2.2 Red Hat 9.0 OS: Linux I am trying to run valgrind in UML (user mode linux). This kernel which is running is modified with some options. I can send also the config file or the binaries as you wish. The UML is running with 512 Mb of Memory. To reproduce the error: * Compile valgrind-3.2.0 with RedHat 9 gcc 3.2.2 (I have tried also with MontaVista gcc 3.4.3) * After UML boot try to start "valgrind ls" * It should get that the system is using 4Gb of memory at SANITY CHECK. Maybe UML is giving this number. I have also tried with valgrind 2.4.1 and it is running without problems. Is there a patch for this version? I would like to use helgrind to find some thread problems in another application. Below I copied the log from the execution. Best regards. Alexandre, ========== MontaVista(R) Linux(R) Carrier Grade Edition 4.0 (0501547) Linux/i686 2.6.12 root@(none):/# valgrind valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory root@(none):/# VALGRIND_LIB=/lib/valgrind valgrind ls Valgrind's memory management: out of memory: newSuperblock's request for 1048576 bytes failed. 4294967296 bytes have already been allocated. Valgrind cannot continue. Sorry. root@(none):/# VALGRIND_LIB=/lib/valgrind valgrind -v ls Valgrind's memory management: out of memory: newSuperblock's request for 1048576 bytes failed. 4294967296 bytes have already been allocated. Valgrind cannot continue. Sorry. root@(none):/#
If you can provide access to a suitable UML setup, I'll have a look. Note that Helgrind is not supported anyway in 3.2.X.
I'm running Fedora Core 6 and I'm getting the same error. It compiles and installs fine, it just gives this error when it's executed.
You mean, you are running FC6 on UML, or UML on FC6, or what exactly?
Same problem as thread "3.2.1: newSuperblock's request for 1048576 bytes failed." on the valgrind-users@lists.sourceforge.net, starting 6 Dec 06.
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;
Fixed in 3.2.2 (r6480/6481).