Your message dated Sat, 16 Apr 2016 23:59:05 +0100
with message-id <[email protected]>
and subject line Re: Bug#820605: Sorry for reporting a non-debian issue
has caused the Debian Bug report #820605,
regarding Valgrind cannot allocate memory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
820605: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820605
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: valgrind
Version: 1:3.11.0-1+b1
Severity: important
Hi,
At least in my installation, valgrind completely fails to work at all.
For a standard "Hello world" C program (and any other), it produces:
| $ valgrind ./hello
| valgrind: mmap(0x600000, 4096) failed in UME with error 12 (Cannot allocate
| memory).
Only the parameters shown after 'mmap' vary. Even worse, calling:
| $ valgrind --help
produces:
| aspacem <<< SHOW_SEGMENTS: out_of_memory (18 segments)
| aspacem 1 segment names in 1 slots
| aspacem freelist is empty
| aspacem (0,4,2) /usr/lib/valgrind/memcheck-amd64-linux
| aspacem 0: RSVN 0000000000-0003ffffff 64m ----- SmFixed
| aspacem 1: 0004000000-0037ffffff 832m
| aspacem 2: FILE 0038000000-0038221fff 2236416 r-x-- d=0x801 i=401634 o=0
(0,4)
| aspacem 3: 0038222000-0038421fff 2097152
| aspacem 4: FILE 0038422000-0038424fff 12288 rw--- d=0x801 i=401634
o=2236416 (0,4)
| aspacem 5: ANON 0038425000-00395dafff 17m rw---
| aspacem 6: 00395db000-0801ffffff 31882m
| aspacem 7: RSVN 0802000000-0802000fff 4096 ----- SmFixed
| aspacem 8: ANON 0802001000-0802400fff 4194304 rwx--
| aspacem 9: 0802401000-0fffffffff 32731m
| aspacem 10: RSVN 1000000000-7ffd29391fff 130996g ----- SmFixed
| aspacem 11: ANON 7ffd29392000-7ffd293b2fff 135168 rw---
| aspacem 12: RSVN 7ffd293b3000-7ffd293c5fff 77824 ----- SmFixed
| aspacem 13: ANON 7ffd293c6000-7ffd293c8fff 12288 r----
| aspacem 14: ANON 7ffd293c9000-7ffd293cafff 8192 r-x--
| aspacem 15: RSVN 7ffd293cb000-ffffffffff5fffff 16383e ----- SmFixed
| aspacem 16: ANON ffffffffff600000-ffffffffff600fff 4096 r-x--
| aspacem 17: RSVN ffffffffff601000-ffffffffffffffff 9m ----- SmFixed
| aspacem >>>
| core : 4,194,304/ 4,194,304 max/curr mmap'd, 0/0 unsplit/split sb
unmmap'd, 20,496/ 20,496 max/curr, 17/ 32944
totalloc-blocks/bytes, 16 searches 8 rzB
| dinfo : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
unmmap'd, 0/ 0 max/curr, 0/ 0
totalloc-blocks/bytes, 0 searches 8 rzB
| client : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
unmmap'd, 0/ 0 max/curr, 0/ 0
totalloc-blocks/bytes, 0 searches 24 rzB
| demangle: 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
unmmap'd, 0/ 0 max/curr, 0/ 0
totalloc-blocks/bytes, 0 searches 8 rzB
| ttaux : 0/ 0 max/curr mmap'd, 0/0 unsplit/split sb
unmmap'd, 0/ 0 max/curr, 0/ 0
totalloc-blocks/bytes, 0 searches 8 rzB
| translate: no SP updates identified
| translate: PX: SPonly 0, UnwRegs 0, AllRegs 0, AllRegsAllInsns 0
| tt/tc: 0 tt lookups requiring 0 probes
| tt/tc: 0 fast-cache updates, 0 flushes
| transtab: new 0 (0 -> 0; ratio 0.0) [0 scs] avg tce size 0
| transtab: dumped 0 (0 -> ??) (sectors recycled 0)
| transtab: discarded 0 (0 -> ??)
| scheduler: 0 event checks.
| scheduler: 0 indir transfers, 0 misses (1 in 0)
| scheduler: 0/0 major/minor sched events.
| sanity: 0 cheap, 0 expensive checks.
|
| Valgrind's memory management: out of memory:
| newSuperblock's request for 4194304 bytes failed.
| 22,925,312 bytes have already been mmap-ed ANONYMOUS.
| Valgrind cannot continue. Sorry.
|
| There are several possible reasons for this.
| - You have some kind of memory limit in place. Look at the
| output of 'ulimit -a'. Is there a limit on the size of
| virtual memory or address space?
| - You have run out of swap space.
| - Valgrind has a bug. If you think this is the case or you are
| not sure, please let us know and we'll try to fix it.
| Please note that programs can take substantially more memory than
| normal when running under Valgrind tools, eg. up to twice or
| more, depending on the tool. On a 64-bit machine, Valgrind
| should be able to make use of up 32GB memory. On a 32-bit
| machine, Valgrind should be able to use all the memory available
| to a single process, up to 4GB if that's how you have your
| kernel configured. Most 32-bit Linux setups allow a maximum of
| 3GB per process.
|
| Whatever the reason, Valgrind cannot continue. Sorry.
I have not set any ulimits and indeed, things look normal:
| $ ulimit -a
| core file size (blocks, -c) 0
| data seg size (kbytes, -d) unlimited
| scheduling priority (-e) 0
| file size (blocks, -f) unlimited
| pending signals (-i) 31620
| max locked memory (kbytes, -l) 64
| max memory size (kbytes, -m) unlimited
| open files (-n) 65536
| pipe size (512 bytes, -p) 8
| POSIX message queues (bytes, -q) 819200
| real-time priority (-r) 0
| stack size (kbytes, -s) 8192
| cpu time (seconds, -t) unlimited
| max user processes (-u) 31620
| virtual memory (kbytes, -v) unlimited
| file locks (-x) unlimited
Additionally, the machine would have 6 GB memory available for valgrind:
| $ free
| total used free shared buff/cache
available
| Mem: 8095784 1713108 88964 60464 6293712
6242548
| Swap: 0 0 0
Since earlier versions of valgrind worked well and no other programs here
report memory shortages, it should not be local problem only. But, if no one
else experiences this problem with valgrind, any hint would be welcome.
Kind regards,
Lars Dölle
--- End Message ---
--- Begin Message ---
On Thu, Apr 14, 2016 at 12:45:42pm +0200, Lars Dölle wrote:
> Since no one confirmed this problem, I looked further for
> local reasons and found that I'm running a self-compiled,
> i.e. non-debian kernel.
>
> Activating the current debian kernel solved this issue.
No problem. Closing this now.
Cheers
signature.asc
Description: PGP signature
--- End Message ---
