Re: Memory Leaks When Using Statistics (was Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up))

2011-03-17 Thread Daniel Wagner

Hi Grant,

Finally, I found some time for debugging.


2) Keeping connman in the stack, but changing the mapping from
MAP_PRIVATE
back to MAP_SHARED such that stats_file_setup fails with -EINVAL (due to
being backed by a JFFS2 file system).


Okay, that tells us at least if stats.c is not involved there is no
memory leak elsewhere. That's kind of nice for the rest bad for me ;)


I have run valgrind for a while and also monitoring the memory map of 
connman with pmap. I don't know if that's enough or good way trying to 
find memory leak. ConnMan run through the whole night with a bit of 
background traffic (mail client polling etc) and I couldn't see any 
change in the pmap


The first entry looks like this:

22403:   ./connmand -n -d src/stats.c
Address   Kbytes RSS   Dirty Mode   Mapping
0040 532 412   0 r-x--  connmand
00685000  36  36  20 rw---  connmand
01325000 132 120 120 rw---[ anon ]
00310500 124 108   0 r-x--  ld-2.13.so
00310521e000   4   4   4 r  ld-2.13.so
00310521f000   4   4   4 rw---  ld-2.13.so
00310522   4   4   4 rw---[ anon ]
003105401604 652   0 r-x--  libc-2.13.so
0031055910002048   0   0 -  libc-2.13.so
003105791000  16  16   8 r  libc-2.13.so
003105795000   4   4   4 rw---  libc-2.13.so
003105796000  24  24  24 rw---[ anon ]
00310580   8   8   0 r-x--  libdl-2.13.so
0031058020002048   0   0 -  libdl-2.13.so
003105a02000   4   4   4 r  libdl-2.13.so
003105a03000   4   4   4 rw---  libdl-2.13.so
003105c0  92  56   0 r-x--  libpthread-2.13.so
003105c170002044   0   0 -  libpthread-2.13.so
003105e16000   4   4   4 r  libpthread-2.13.so
003105e17000   4   4   4 rw---  libpthread-2.13.so
003105e18000  16   4   4 rw---[ anon ]
00310640  28  16   0 r-x--  libxtables.so.5.0.0
0031064070002048   0   0 -  libxtables.so.5.0.0
003106607000   4   4   4 rw---  libxtables.so.5.0.0
003106c0  28  20   0 r-x--  librt-2.13.so
003106c070002044   0   0 -  librt-2.13.so
003106e06000   4   4   4 r  librt-2.13.so
003106e07000   4   4   4 rw---  librt-2.13.so
00310740  92  44   0 r-x--  libresolv-2.13.so
0031074170002044   0   0 -  libresolv-2.13.so
003107616000   4   4   4 r  libresolv-2.13.so
003107617000   4   4   4 rw---  libresolv-2.13.so
003107618000   8   0   0 rw---[ anon ]
003107801048 424   0 r-x--  libglib-2.0.so.0.2600.0
0031079060002044   0   0 -  libglib-2.0.so.0.2600.0
003107b05000   4   4   4 rw---  libglib-2.0.so.0.2600.0
003107b06000   4   4   4 rw---[ anon ]
00310840 268 208   0 r-x--  libdbus-1.so.3.5.2
0031084430002044   0   0 -  libdbus-1.so.3.5.2
003108642000   4   4   4 r  libdbus-1.so.3.5.2
003108643000   4   4   4 rw---  libdbus-1.so.3.5.2
00310b00  16  12   0 r-x--  libcap-ng.so.0.0.0
00310b0040002044   0   0 -  libcap-ng.so.0.0.0
00310b203000   4   4   4 r  libcap-ng.so.0.0.0
00310b204000   4   4   4 rw---  libcap-ng.so.0.0.0
7f295bebf000   4   4   0 r-x--  iospm.so
7f295bec2044   0   0 -  iospm.so
7f295c0bf000   4   4   4 rw---  iospm.so
7f295c0c  24  24  24 rw---[ anon ]
7f295c0e2000  16  16  12 rw-s- 
ethernet_002481c57c73_cable.data

7f295c0e6000  28  24   0 r--s-  gconv-modules.cache
7f295c0ed000   4   4   4 rw---[ anon ]
7fff6132b000 132  24  24 rw---[ stack ]
7fff613ff000   4   4   0 r-x--[ anon ]
ff60   4   0   0 r-x--[ anon ]
  --  --  --
total kB   248202340 320

and the current (14 hours later) one looks like this:
22403:   ./connmand -n -d src/stats.c
Address   Kbytes RSS   Dirty Mode   Mapping
0040 532 412   0 r-x--  connmand
00685000  36  36  20 rw---  connmand
01325000 132 120 120 rw---[ anon ]
00310500 124 108   0 r-x--  ld-2.13.so
00310521e000   4   4   4 r  ld-2.13.so
00310521f000   4   4   4 rw---  ld-2.13.so
00310522   4   4   4 rw---[ anon ]
003105401604 652   0 r-x--  

Re: Memory Leaks When Using Statistics (was Re: [PATCH 1/1]: Fix Memory-map and Double-free Errors in Statistics Handling (was Re: Connman-0.67 Crashes and/or Hangs on Start-up))

2011-02-17 Thread Jukka Rissanen
Hi Grant,

On 17 February 2011 20:10, Grant Erickson maratho...@gmail.com wrote:
 To isolate the leaks, I systematically eliminated processes from the system
 until I was left with:

    - syslogd
    - klogd
    - wpa_supplicant
    - dbus-daemon
    - connmand


I have run connmand under valgrind and it reports memory leaks in
gsupplicant code. I sent earlier some memoryleak patches in various
parts of connman but unfortunately I have lately had no time to find
out where the latest supplicant leaks are.

Regards,
Jukka
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman