[#5291] crash handler seems to leak memory
Submitted By: Mike Frysinger
Open Date
2009-06-22 23:40:06 Close Date
2009-06-25 16:07:04
Priority:
Medium Assignee:
Nobody
Status:
Closed Fixed In Release:
N/A
Found In Release:
2010R1 Release:
Category:
N/A Board:
N/A
Processor:
BF537 Silicon Revision:
0.2
Is this bug repeatable?:
Yes Resolution:
Rejected
Uboot version or rev.:
Toolchain version or rev.:
trunk
App binary format:
N/A
Summary: crash handler seems to leak memory
Details:
while writing a test case to try and read all supervisor mmrs from userspace, it seems we leak a little bit of memory with every crashed process. removing the crashing line (so that the child only exits) shows no memory leak. there is no change in /proc/maps.
memory at boot:
total used free shared buffers
Mem: 55404 7564 47840 0 0
memory after running the simple test case for a little while:
total used free shared buffers
Mem: 55404 12904 42500 0 0
simple test case:
#include <signal.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
if (argc == 2) {
unsigned char *mmr = (void *)0xffc00000;
return *mmr;
}
signal(SIGCHLD, SIG_IGN);
while (1)
if (vfork() == 0)
_exit(execlp(argv[0], argv[0], "-c", NULL));
}
Follow-ups
--- Robin Getz 2009-06-23 00:27:42
cat you tell where it is going (via /proc/meminfo?)
(Just to make sure it isn't file cache).
--- Mike Frysinger 2009-06-23 00:36:33
that's why i did `echo 3 > /proc/sys/vm/drop_caches` originally ... no
change
before/after (with unchanged entries dropped):
MemFree: 47788 kB
Cached: 4384 kB
Active: 520 kB
Inactive: 3848 kB
Active(file): 520 kB
Inactive(file): 3848 kB
MmapCopy: 1940 kB
Slab: 1092 kB
SReclaimable: 632 kB
after:
MemFree: 38860 kB
Cached: 12756 kB
Active: 536 kB
Inactive: 12220 kB
Active(file): 536 kB
Inactive(file): 12220 kB
MmapCopy: 2456 kB
Slab: 1100 kB
SReclaimable: 640 kB
--- Robin Getz 2009-06-23 00:44:44
Hmm - difference with flat vs fdpic?
(I'm wondering if some of the mmap changes don't release files when a process
is killed).
-Robin
--- Mike Frysinger 2009-06-23 00:53:27
original test was with FLAT. it's hard to say whether running with FDPIC has a
similar memleak ... i dont think it does.
i'll let it run for a (long) while and see what happens.
--- Mike Frysinger 2009-06-23 12:46:09
it seemed to die after 5 minutes when running as FDPIC
the fork isnt needed ... i just implemented something with setjmp/longjmp and
same leak occurs
with the latest crash test, you should be able to reproduce by doing:
traps_test -b r1
and then watch `free`
--- Robin Getz 2009-06-23 14:33:18
Sorry - to confirm - you did something with setjmp/longjmp (no crash) or was it
crashing?
-Robin
--- Mike Frysinger 2009-06-23 14:40:12
there are no problems with using setjmp/longjmp vs vfork. the crash is still
because of the reading of invalid memory locations.
--- Robin Getz 2009-06-23 17:05:19
?
root:/> grep -v "0 k" /proc/meminfo
MemTotal: 62372 kB
MemFree: 53472 kB
Cached: 5892 kB
Active: 488 kB
Inactive: 5404 kB
Active(file): 488 kB
Inactive(file): 5404 kB
MmapCopy: 1456 kB
Slab: 1356 kB
SReclaimable: 896 kB
CommitLimit: 31184 kB
root:/> traps_test -b r4
0 TRAP
root:/> echo 3 > proc/sys/vm/drop_caches
root:/> grep -v "0 k" /proc/meminfo
MemTotal: 62372 kB
MemFree: 53472 kB
Cached: 5892 kB
Active: 488 kB
Inactive: 5404 kB
Active(file): 488 kB
Inactive(file): 5404 kB
MmapCopy: 1456 kB
Slab: 1356 kB
SReclaimable: 896 kB
CommitLimit: 31184 kB
--- Mike Frysinger 2009-06-24 15:05:34
i dont think your test worked. `traps_test -b r4` should not result in a
"TRAP". it should run until you hit ctrl+c.
i'm using gcc-4.3.3 with BF537-STAMP_defconfig on a bf537-0.2 in case that
makes a difference
so what i did (waited like 10 seconds between each free):
root:/> dmesg -n1
root:/> traps_test -b r1 &
root:/> free
total used free shared buffers
Mem: 55252 8292 46960 0 0
root:/> free
total used free shared buffers
Mem: 55252 9268 45984 0 0
root:/> free
total used free shared buffers
Mem: 55252 14276 40976 0 0
root:/> free
total used free shared buffers
Mem: 55252 22088 33164 0 0
--- Mike Frysinger 2009-06-25 16:07:04
ok, i think i'm just being stupid and forgot to turn off logging. so the memory
leak is klogd eating up the ram.
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found