[#5291] crash handler seems to leak memory

Document created by Aaronwu Employee on Sep 4, 2013
Version 1Show Document
  • View in full screen mode

[#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

Attachments

    Outcomes