[dev] [wmii] likely memory leak
Hi all, I use wmii-3.9.2-r1 (gentoo ebuild) on my workstation. Today I looked at memory usage and saw that wmii had been occupying all memory and swap. Uptime was about three month. I am trying to reproduce this issue at home with wmii- (hg, cloned today). Seems the devel version has this issue too. Take a look. $ ps axu | grep wmii$ amaora3045 0.2 0.4 6228 2480 tty1 S19:37 0:00 wmii After a couple hours. $ ps axu | grep wmii$ amaora3045 0.1 0.7 7404 3620 tty1 S19:37 0:07 wmii I did not find any non-outdated mentions about such issue. Strangely, does anyone observe this issue? Thanks, Roman
Re: [dev] [wmii] likely memory leak
On Wed, Feb 23, 2011 at 02:40:18PM -0500, Kris Maglione wrote:
> On Fri, Feb 18, 2011 at 09:15:14PM +0300, Roman Belov wrote:
> >I use wmii-3.9.2-r1 (gentoo ebuild) on my workstation. Today I looked at
> >memory usage and saw that wmii had been occupying all memory and swap.
> >Uptime was about three month.
> >
> >I am trying to reproduce this issue at home with wmii- (hg, cloned
> >today).
> >Seems the devel version has this issue too.
>
> Ok, I looked into this and it turns out that it wasn't a leak.
> Certain structures used in the filesystem are allocated from a
> free list because they're used in huge numbers. However, in one
> particular place, a structure was allocated directly rather than
> taken from the free list, and was re-added to the free list
> later, and thus the free list grew without bound by one
> structure for each filesystem walk. It should be fixed by
> revision 141:339db5c6d2c9 in the libixp repo.
>
It did not fix the problem, that free list is actually bounded now (I
checked) but memory usage still grows.
I have performed a little investigation. Valgrind shows that it is not a
leak again. So I captured and analysed call logs of malloc/free/etc.
functions. I found that some block of 48 bytes is periodically (likely
it is status line update activity) allocated but is never freed. From
gdb stack backtraces I see only one place where such block is allocated.
#0 0xb749b0b6 in malloc () from /lib/libc.so.6
No symbol table info available.
#1 0x0806a22b in ixp_emalloc (size=48) at util.c:198
ret = 0x1
#2 0x0806a25d in ixp_emallocz (size=48) at util.c:207
ret = 0xbff42688
#3 0x08066bc3 in createfid (map=0x80d632c, fid=2, p9conn=0x80d6320) at
request.c:91
f = 0x80e14f8
#4 0x080674a4 in handlereq (r=0x80e1240) at request.c:296
p9conn = 0x80d6320
srv = 0x80806e0
#5 0x08066df4 in handlefcall (c=0x80d5278) at request.c:146
(Dropped a lot of data)
p9conn = 0x80d6320
req = 0x80e1240
#6 0x080681e3 in handle_conns (s=0x80866c0) at server.c:118
c = 0x80d5278
n = 0x80c5d88
#7 0x08068316 in ixp_serverloop (srv=0x80866c0) at server.c:169
tvp = 0xbff428dc
tv = {tv_sec = 0, tv_usec = 381988}
timeout = 382
r = 1
#8 0x0805c903 in main (argc=0, argv=0xbff42a78) at main.c:436
oargv = 0xbff42a74
wmiirc = 0x807c3bc "wmiirc"
i = -1074517560
_argtmp = 0
_inargv = 0
_argv = 0x0
Unfortunately, I am not familiar with libixp code to decide what is
wrong.
Re: [dev] [wmii] likely memory leak
On Tue, Mar 01, 2011 at 12:12:09AM +0300, Roman Belov wrote:
> On Wed, Feb 23, 2011 at 02:40:18PM -0500, Kris Maglione wrote:
> > On Fri, Feb 18, 2011 at 09:15:14PM +0300, Roman Belov wrote:
> > >I use wmii-3.9.2-r1 (gentoo ebuild) on my workstation. Today I looked at
> > >memory usage and saw that wmii had been occupying all memory and swap.
> > >Uptime was about three month.
> > >
> > >I am trying to reproduce this issue at home with wmii- (hg, cloned
> > >today).
> > >Seems the devel version has this issue too.
> >
> > Ok, I looked into this and it turns out that it wasn't a leak.
> > Certain structures used in the filesystem are allocated from a
> > free list because they're used in huge numbers. However, in one
> > particular place, a structure was allocated directly rather than
> > taken from the free list, and was re-added to the free list
> > later, and thus the free list grew without bound by one
> > structure for each filesystem walk. It should be fixed by
> > revision 141:339db5c6d2c9 in the libixp repo.
> >
>
> It did not fix the problem, that free list is actually bounded now (I
> checked) but memory usage still grows.
>
> I have performed a little investigation. Valgrind shows that it is not a
> leak again. So I captured and analysed call logs of malloc/free/etc.
> functions. I found that some block of 48 bytes is periodically (likely
> it is status line update activity) allocated but is never freed. From
> gdb stack backtraces I see only one place where such block is allocated.
>
> #0 0xb749b0b6 in malloc () from /lib/libc.so.6
> No symbol table info available.
> #1 0x0806a22b in ixp_emalloc (size=48) at util.c:198
> ret = 0x1
> #2 0x0806a25d in ixp_emallocz (size=48) at util.c:207
> ret = 0xbff42688
> #3 0x08066bc3 in createfid (map=0x80d632c, fid=2, p9conn=0x80d6320) at
> request.c:91
> f = 0x80e14f8
> #4 0x080674a4 in handlereq (r=0x80e1240) at request.c:296
> p9conn = 0x80d6320
> srv = 0x80806e0
> #5 0x08066df4 in handlefcall (c=0x80d5278) at request.c:146
> (Dropped a lot of data)
> p9conn = 0x80d6320
> req = 0x80e1240
> #6 0x080681e3 in handle_conns (s=0x80866c0) at server.c:118
> c = 0x80d5278
> n = 0x80c5d88
> #7 0x08068316 in ixp_serverloop (srv=0x80866c0) at server.c:169
> tvp = 0xbff428dc
> tv = {tv_sec = 0, tv_usec = 381988}
> timeout = 382
> r = 1
> #8 0x0805c903 in main (argc=0, argv=0xbff42a78) at main.c:436
> oargv = 0xbff42a74
> wmiirc = 0x807c3bc "wmiirc"
> i = -1074517560
> _argtmp = 0
> _inargv = 0
> _argv = 0x0
>
> Unfortunately, I am not familiar with libixp code to decide what is
> wrong.
>
Sorry for misinformation. It was wrong stack trace. This call does not
correspond the target malloc(48) without free(). I will update this
thread a bit later.
Re: [dev] [wmii] likely memory leak
On Wed, Mar 02, 2011 at 12:00:12AM +0300, Roman Belov wrote: > Sorry for misinformation. It was wrong stack trace. This call does not > correspond the target malloc(48) without free(). I will update this > thread a bit later. > I confused a various versions of wmii/libixp. Actually, problem was fixed. Thanks and sorry again for this useless mail flooding.
