I'm trying to profile a reporting tool valgrind runs out of memory. /home/msilverm/valgrind/bin/valgrind --tool=callgrind --stats=yes runrep -f empty -u accessadmin The output is attached to this bug report. My system has a lot of memory: [~] % free -mt total used free shared buffers cached Mem: 129062 125643 3418 0 172 121670 -/+ buffers/cache: 3801 125260 Swap: 32767 0 32767 Total: 161830 125644 36186
Created attachment 83591 [details] output from valgrind
Hmm.. the stats numbers seem quite normal, and this definitly does not look like extensive memory usage by Callgrind. It does run fine with memcheck? Is this a 32-bit binary? You could run with "--trace-syscalls=yes" to see the failing syscall.
Yes, memcheck works fine. The binary is 64-bit. I'm not sure what the syscalls tells me, but here is part of the output with the failure: SYSCALL[25411,1]( 12) sys_brk ( 0x4800000 ) --> [pre-success] Success(0x0:0x4700000) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 0, 0xffeff5380, 0xffeff5300, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 13) sys_rt_sigaction ( 17, 0x0, 0xffeff5110, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 2, 0xffeff5300, 0x0, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 35) sys_nanosleep ( 0xffeff5400, 0xffeff5400 ) --> [async] ... SYSCALL[25411,1]( 35) ... [async] --> Success(0x0:0x0) SYSCALL[25411,1]( 12) sys_brk ( 0x4800000 ) --> [pre-success] Success(0x0:0x4700000) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 0, 0xffeff5380, 0xffeff5300, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 13) sys_rt_sigaction ( 17, 0x0, 0xffeff5110, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 2, 0xffeff5300, 0x0, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 35) sys_nanosleep ( 0xffeff5400, 0xffeff5400 ) --> [async] ... SYSCALL[25411,1]( 35) ... [async] --> Success(0x0:0x0) SYSCALL[25411,1]( 12) sys_brk ( 0x4800000 ) --> [pre-success] Success(0x0:0x4700000) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 0, 0xffeff5380, 0xffeff5300, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 13) sys_rt_sigaction ( 17, 0x0, 0xffeff5110, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 2, 0xffeff5300, 0x0, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 35) sys_nanosleep ( 0xffeff5400, 0xffeff5400 ) --> [async] ... SYSCALL[25411,1]( 35) ... [async] --> Success(0x0:0x0) SYSCALL[25411,1]( 12) sys_brk ( 0x4800000 ) --> [pre-success] Success(0x0:0x4700000) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 0, 0xffeff5380, 0xffeff5300, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 13) sys_rt_sigaction ( 17, 0x0, 0xffeff5110, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 14) sys_rt_sigprocmask ( 2, 0xffeff5300, 0x0, 8 ) --> [pre-success] Success(0x0:0x0) SYSCALL[25411,1]( 35) sys_nanosleep ( 0xffeff5400, 0xffeff5400 ) --> [async] ... SYSCALL[25411,1]( 35) ... [async] --> Success(0x0:0x0) SYSCALL[25411,1]( 12) sys_brk ( 0x4800000 ) --> [pre-success] Success(0x0:0x4700000) SYSCALL[25411,1]( 1) sys_write ( 2, 0xffeff2b50, 51 ) --> [async] ... Currently in routine smalloc.cpp: getMemory(size) SYSCALL[25411,1]( 1) ... [async] --> Success(0x0:0x33) SYSCALL[25411,1]( 1) sys_write ( 2, 0x25116d8, 43 ) --> [async] ... Computer is out of memory allocating heap. SYSCALL[25411,1]( 1) ... [async] --> Success(0x0:0x2b) SYSCALL[25411,1]( 1) sys_write ( 2, 0xffeff2b50, 32 ) --> [async] ... We had asked for 1048576 bytes. SYSCALL[25411,1]( 1) ... [async] --> Success(0x0:0x20) SYSCALL[25411,1]( 1) sys_write ( 2, 0xffeff2b50, 11 ) --> [async] ... errno = 12
(In reply to comment #3) > SYSCALL[25411,1]( 1) sys_write ( 2, 0xffeff2b50, 51 ) --> [async] ... > Currently in routine smalloc.cpp: getMemory(size) > SYSCALL[25411,1]( 1) ... [async] --> Success(0x0:0x33) > SYSCALL[25411,1]( 1) sys_write ( 2, 0x25116d8, 43 ) --> [async] ... > Computer is out of memory allocating heap. Can you start valgrind with --vgdb-error=0, connect with gdb+vgdb and put a break on the line producing the above message. Then do (in gdb): monitor v.info memory aspacemgr This will show the full state of the various memory arenas of valgrind and the layout of the Valgrind address space manager. Thanks (you might also run in parallel a version of your program natively and under valgrind+callgrind+vgdb, put breaks at various places and see when the behaviour diverges)
10 years waiting for an aspacemgr log. Closing this.