I had it sort-of-working with much hacking, but after some
more musing on it I desided that the hack to make it work
is far too ugly and also fragile. I eventually removed it
in commits c4ada7934307c6ef0b5b207df13a54fecd4ad81d
and d5762932fbcbc0a385047945276f10e2f3fea12d.
1.13.x are the last vers
The kernel and uClibc are from www.uclinux.org release 20080808.
This is almost certainly a uclinux bug, in their modified version of the
nommu
C library. You need to ask them about it.
I have done some experimenting with uClinux-dist and kernel 2.6.29 and the
same
busybox seems to be ru
If it was kernel, gcc would probably be triggering it. It's almost
certainly
a uClibc bug. You're using a 3.5 year old version on a platform variant
(nommu) that really didn't have much testing back then.
Which uClibc source tree are you using, what's your .config, and what
target
architectu
Ok, I'm out of ideas.
Any possibility that the problem is kernel/library related?
I am running uClinux with 2.6.25 kernel and 0.9.29 uClibc.
--
Piotr
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Can you compile the following test program:
#include
#include
int main(int argc, char **argv)
{
while (1) {
write(1, ".", 1);
execv("/proc/self/exe", argv);
}
return 0;
}
via "gcc -Wall testprog.c", run it and report whether you see
free memory disappearing?
--
vda
N
Here is my 'top' output (how would I get output formated like your's?)
By pressing 's'
When I press 's', top terminates with the following message:
top: no process info in /proc
I would like you to try more things.
For example:
Does "while true; do cat
Next experiment: find and set LEAK
What do you see in top?
Here is my 'top' output (how would I get output formated like your's?) just
after the system restart:
Mem: 4620K used, 10096K free, 0K shrd, 8K buff, 752K cached
CPU: 22.2% usr 16.6% sys 0.0% nic 61.1% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.00 0.00 0.00 1/
What do you see in top?
Does the leak depend on applet called in the loop?
Try "while true; do sleep 0; done" and "while true; do true; done" -
do these also leak?
Have to add top to my BB and do more tests shortly.
Does the leak go away if you turn off FEATURE_PREFER_APPLETS
and FEATURE_S
With the patch applied, the problem persists.
--
Piotr
On Tue, Dec 21, 2010 at 9:17 PM, Denys Vlasenko
Here is the fix:
http://busybox.net/downloads/fixes-1.18.1/busybox-1.18.1-hush.patch
--
vda
___
busybox mailing list
busybox@busybox.net
http://
The email seems to disappeared. Here is what I sent:
Hi All,
With BB 1.18.1 on NOMMU system and using hush (all .config is attached) I am
running the following command:
# while true; do free; done
The free memory goes done and system becomes unstable - various processes
are being killed by
mem-leak.config
Description: Binary data
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
On Wednesday 14 April 2010 01:01:08 Steve Bennett wrote:
On 13/04/2010, at 11:09 AM, Rob Landley wrote:
> On Tuesday 13 April 2010 10:08:56 Kim B. Heino wrote:
>> BusyBox 1.16.1 on a small armv4tl system:
>>
>> $ time hwclock -w
>> real 0m 24.34s
>> user 0m 0.00s
>> sys 0m 0.00s
>>
>> $ time hwc
On Wednesday 14 April 2010 01:01:08 Steve Bennett wrote:
On 13/04/2010, at 11:09 AM, Rob Landley wrote:
> On Tuesday 13 April 2010 10:08:56 Kim B. Heino wrote:
>> BusyBox 1.16.1 on a small armv4tl system:
>>
>> $ time hwclock -w
>> real0m 24.34s
>> user0m 0.00s
>> sys 0m 0.00s
>>
>> $
> Do you see inotifyd RSS going up, or some other process?
I cannot see RSS - for my system ENABLE_DESKTOP is set to 0.
You may replace #if ENABLE_DESKTOP by #if 1 at the top of ps.c,
then
ps -o pid,comm,rss
will work.
On my system, at least for bb 1.14.0, RSS is zero for all processes all
> Do you see inotifyd RSS going up, or some other process?
I cannot see RSS - for my system ENABLE_DESKTOP is set to 0.
You may replace #if ENABLE_DESKTOP by #if 1 at the top of ps.c,
then
ps -o pid,comm,rss
will work.
Will try it shortly.
> Try 1.13.4, 1.14.0, 1.14.1, 1.14.2, 1.14.3
Do you see inotifyd RSS going up, or some other process?
I cannot see RSS - for my system ENABLE_DESKTOP is set to 0.
Try 1.13.4, 1.14.0, 1.14.1, 1.14.2, 1.14.3 and let us know
at which version it started.
I have noticed that my original bb 1.13.1 was built with 'msh' and not
'hush'. So I
>> With bb-1.15.2 my system looses 40K to 52K of RAM as reported by the
>> free
>> command.
>
> Loses 40K to 52K per what period of time? Memory leak is characterized
> by unlimited growth of used memory, not by fixed amount.
In my case, the above sequence of 3 inotifyd is triggered every 5 minu
On Monday 16 November 2009 21:37, Piotr Grudzinski wrote:
I do have 3 inotifyd processes.
The first - waits for some file.
The second waits for file created by the script called by first inotifyd
and
calls wget program (not from bb).
The third is triggered by the file created by wget program
inotifyd is very simple. It has exactly one allocation,
which usually does not trigger. From code inspection
it is properly freed.
Just for test I rebuild bb-1.13.1 with inotifyd.c from bb-1.15.2
It runs OK. So, inotifyd must be fine.
However, each inotify event runs a program to handle
the e
Hello!
I just upgraded BB from 1.13.1 to 1.15.2 (static build for no-mmu system) and
have noticed the amount of free RAM going down with time.
The free RAM changes seem to correlate quite well with inotifyd applet's
activities.
Have anybody else noticed it?
Best Regards,
Piotr
> Running busybox ver. 1.15.0
>
> I have expected the ifplugd applet to detect if/when my Ethernet
> cable is plugged and unplugged. Here is my command line:
>
> # ifplugd -a -n -i eth0 -p -m i &
>
> My action script - /etc/ifplugd/ifplugd.action - is never called
> when network cable is plugged
Running busybox ver. 1.15.0
I have expected the ifplugd applet to detect if/when my Ethernet cable is
plugged and unplugged.
Here is my command line:
# ifplugd -a -n -i eth0 -p -m i &
My action script - /etc/ifplugd/ifplugd.action - is never called when network
cable is plugged or unplugged.
B
It woks fine now. Thanks!
--
Piotr
- Original Message -
> > Running bb v1.15.0.svn (2009-08-14) and hush.
^^
> >
> > The runsv applet (part of runit utility) calls
> my finish script with an> argument set to "-1". busybox seems to
> assume
Running bb v1.15.0.svn (2009-08-14) and hush.
The runsv applet (part of runit utility) calls my finish script with an
argument set to "-1". busybox seems to assume that this is an option and
displays:
/bin/sh: invalid option -- 1
The same happens if I call the script with an argument conta
>>> So -w N would result in idling at most N seconds.
>>
>> I have tried -w 5 and -w 1. It was timing out after 3-4 minutes.
>> Any suggestions ?
>
> It means your SMTP session has run OK, I presume, so no timeout limit
> was reached.
> If you post exact cmdline you use along with strace log of a s
>>> Right now I see it is not involved.
>>
>> So the time-out is not used when connecting to the mail server?
>>
> I was wrong. Indeed it is used. Look at mailutils/mail.c:
>
>
> const FAST_FUNC char *command(const char *fmt, const char *param)
> {
> const char *msg = fmt;
> if (timeout)
> al
>>
>> 1. With SMTPHOST sendmail works fine; with -H it fails (see below):
>
> Again, -H specifies connection helper (e.g. openssl), not host. To
> specify the host use -S.
> Look at the relevant portion:
>
> -
> // N.B. -H and -S are mutually exclusive so they do not spoil opt_connect
> // conn
Hi all,
Running BB 1.13.1
I have some problems with -H and -w options of the sendmail applet.
1. With SMTPHOST sendmail works fine; with -H it fails (see below):
# SMTPHOST=my.out.mail.server sendmail -f pi...@my.com < testmail
# sendmail -H my.out.mail.server -f pi...@my.com < testmail
my.out.
Vladimir,
1. When I was discovering that the inotify existed you were already an expert.
2. In my code if I open I close; the same with the add - remove pair.
3. Now I know that inotify can remove some watches internally and the close()
was implemented to do all the required cleanup. So I would j
According to http://www.linuxjournal.com/article/8478 - close() will do all the
required cleanup job.
"To destroy any existing watches, pending events and the inotify instance
itself, invoke the close() system call on the inotify instance's file
descriptor."
Best Regards,
Piotr
I would g
An old habit. I trust nobody; always prefer cleanup after myself.
Piotr
> Hi Piotr,
>
> Your Date: seems to be off: 2008-09-25??
>
> On Thursday 25 September 2008 18:24, Piotr Grudzinski wrote:
>> Would it be too much of a trouble to have inotify_rm_watch()
>>
Here are some problems with the date applet and ISO-8601 as of BB 1.12.1
1. Colon separator - use it (extended format) or not (basic format). BB seems
to mix both:
# date -Iseconds
2008-11-25T12:46:43-0500
There is a missing colon in -0500 (the difference between local time and UTC).
2. A 'Z'
Would it be too much of a trouble to have inotify_rm_watch() for each
inotify_add_watch() call and a close() matching inotify_init()?
Piotr___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
So I applied patches to inotifyd.c from SVN and can see the same problem. If
the only event is IN_IGNORED
the 'goto done' will never be executed.
I tried it with BB 1.12.1.
Always apply patches against current SVN unless the precise version is
specified, Piotr. I should have told that, s
I tried it with BB 1.12.1. If the only event is IN_IGNORED (0x8000) the if(m)
is false and 'goto done' is never executed.
On my system the agent program is always called with one event at a time.
Piotr
So we should implicitly add IN_IGNORED to the watching mask regardless the
user specifie
I have tried it with BB 1.12.1. Seems to be OK.
Thanks,
Piotr
When the watched file becomes invalid, the agent program has to be informed
about it and inotifyd should terminate.
I think it is purely agent's headache. Your scenario is one special case,
Piotr -- how many another ones you
When the watched file becomes invalid, the agent program has to be informed
about it and inotifyd should terminate.
Piotr
inotify listens to changes to inode, not file name. mv f1 f2 effectively
_deletes_ target file if the latter exists. Thus, the watch becomes invalid.
This behaviour is i
YES
But, with this solution, it seems that my handler is left waiting for
events after it was told not to expect any anymore.
You mean in your scenario you get event on specified file only once?
--
Vladimir
___
busybox mailing list
bu
Will try it later.
But, with this solution, it seems that my handler is left waiting for events
after it was told not to expect any anymore.
Piotr
inotifyd: exec echo 8000hello
Aha. 8000 is IN_IGNORED. We should bitwise AND received event mask with
0x0FFF.
Indeed, if
There are two files: hello and hello_tmp. I do:
# mv hello_tmp hello
Result for all events:
inotifyd: exec echo 0400D hello
D hello
inotifyd: exec echo 8000hello
hello
And if only M is specified:
inotifyd: exec echo 8000hello
hello
Regards,
Piot
# inotifyd /home/piotr/myhandler /var/tmp/myfiles/data:M
The 'data' file exists. New file 'data_tmp' is created. 'data_tmp' is renamed
to 'data'.
Piotr
No change. Still no M.
Strange enough.
Let me see how you call inotifyd.
--
Vladimir
__
Your example works for me too.
Piotr
> On Friday 14 November 2008 23:02, Piotr Grudzinski wrote:
>> No change. Still no M.
>
> Works for me:
>
> # ./busybox inotifyd echo TODO_config_nommu
> M TODO_config_nommu
>
> (I did "mv TODO_config_nom
Having 11 letters for other events I tried letter 'O' for 'unwrittable file is
closed' which failed. A zero was
expected which I find interesting: why one number and eleven letters?
:-)
Piotr
3. Was the number zero intended to be used for the 'unwrittable file is
closed' event?
Didn't ca
No change. Still no M.
BR,
Piotr
2. The letter M - for the 'self is moved' event - is never passed to my
agent script; the script runs but there is nothing printable in the 1st
parameter.
I'll take closer a look.
Seems we had classic buffer overflow :)
Will you try attached pat
Hi,
I am running busybox 1.12.1 on uClinux (from uClinux.org) on ARM9 nommu system.
Here are my problems with inotifyd applet:
1. Every time my agent script runs, a new zombie process is left behind. The
same script runs cleanly with a cron program. (this is not the busybox cron).
2. The letter
45 matches
Mail list logo
