[BusyBox] Some more busybox issues...

[Erik Andersen]

On Thu Mar 15, 2001 at 07:40:35PM +0100, Andreas Neuhaus wrote:
> hello all,
> 
> while others were, i saw that my fix suggestions were not included into cvs
> yet. do i have to submit an official bugreport via the web page or is it
> usually ok to post suggestions to busybox at busybox.net?
> 
> sorry, i don't want to hurry you, i was just thinking those things are
> important enough to fix before releasing 0.50.
> 
> 1) sh.c fails compiling with uClibc (called object is not a function). fix
> is in one of my previous mails

This is a uClibc bug, not a sh.c bug.  I'll be fixing uClibc
as soon as I get the busybox release out.

> 2) linuxrc never works because applets.h uses BB_LINUXRC which is never
> defined. fix is in one of my previous mails

fixed now, thanks

> here are some more things i found. i'm using the latest busybox from cvs
> linked against the latest uClibc from cvs on a 2.4.2 linux kernel (devfs
> mounted, but no devfsd):
> 
> 3) lash export behaves strange when setting a var that was defined before.
> the old env entry isn't removed. e.g.: when PATH=/bin and doing export
> PATH=/sbin:$PATH there are 2 PATH entries afterwards: one says PATH=/bin,
> the other PATH=/sbin:/bin. doing this again results in 3 PATH entries.

I'm not seeing this:

/home/andersen/CVS/busybox $ export FOO=bar
/home/andersen/CVS/busybox $ export FOO=baz
/home/andersen/CVS/busybox $ export FOO=bat:$FOO
/home/andersen/CVS/busybox $ env | grep FOO
FOO=bat:baz


> 4) ps does not work for me. the sccanf calls in parse_proc_status in ps.c
> always return an empty string. i discovered this when searching for the
> reason why kernel processes are listed as "[]" instead of "[swapper]" and
> process status is missing completely.

Ok, I do see some wierdness there with uClibc.

> 5) argv[0]="init"; in init.c does not work for some reason. this results in
> init staying as /linuxrc in the process list. this furtheron results in
> failure of reboot, halt and poweroff because they are unable to find the
> "init" process.

Hmm.  Ok, I'll take a look.   

> 6) kernel 2.4.2 allows it to run /sbin/init from linuxrc (see
> Documentation/initrd.txt). should busybox/init.c really instist on being pid
> 1 when running as init?

Here is the problem.  Some folk expect to run init and have it act like
sysvinit ('init 3' type of stuff).  If take out the check, and then run init
when it isn't really being the init process, it will still happily reboot your
system when you kill it.  Not very desirable behavior.

> 7) at several places (e.g. init.c) elements in linked lists are deleted
> while iterating through it. this can be potentially dangerous because the
> next pointer is used from an already freed element. e.g. in init.c line 957:
>         for (a = initActionList; a; a = a->nextPtr) {
>                 if (a->action == ONCE) {
>                         run(a->process, a->console, FALSE);
>                         delete_initAction(a);
>                 }
>         }
> when delete_initAction(a); returnes, a was usually free()d. but the for loop
> uses a->nextPtr to get the next element. i didn't run into problems with
> this, but it seems like this could become a problem(?).

Yes, this is an important bug.  There must be a temp variable
added.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--