[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    RE: Possible init bug
From:       James Limbouris <james () digitalmatter ! com ! au>
Date:       2011-01-25 3:45:41
Message-ID: 840A81C1B782724A8EB52725BD519EFFCD94 () MBX20 ! 4emm ! local
[Download RAW message or body]

Hi,

I went back to my inittab to collect the slabinfo data, and found that there was no \
problem unless the process was being spawned on /dev/ttGS0 - a usb gadget CDC driver. \
So I assume the bug is there, explaining the increasing kobjects, which I would have \
thought couldn't be allocated by init.

Thanks for responding.

Regards,
James

> -----Original Message-----
> From: Denys Vlasenko [mailto:vda.linux@googlemail.com]
> Sent: Tuesday, 25 January 2011 11:19 AM
> To: busybox@busybox.net
> Cc: James Limbouris
> Subject: Re: Possible init bug
> 
> On Tuesday 25 January 2011 03:25, James Limbouris wrote:
> > Hi All,
> > 
> > I am using busybox 1.17.1 in an ARM embedded system, and I have found
> > a bug in _something_, though it may not be busybox itself. When I have
> > a respawn line in my inittab, pointing to a non-existent or quickly
> > exiting binary, I find that memory is slowly leaked - roughly 12 kB
> > every
> > 2 or 3 seconds. The memory doesn't go to any user processes, and when
> > the kernel is compiled with kmemleak, I see an ever increasing number
> > of kmemleak_object's in /proc/slabinfo (but no leaks reported by
> > kmemleak).
> 
> And without kmemleak compiled in, what line(s) in /proc/slabinfo show
> growth?
> 
> Are you sure nothing in top show unbounded growth?
> 
> Post "top -bmn1" output when you already see a considerable leak.
> --
> vda
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]