[BusyBox] Some more busybox issues...

[Andreas Neuhaus]

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

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

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.

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.

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.

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?

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(?).

regards,
andreas neuhaus
--
Life could be so much easier if we could just look at the source code...
  .~.
  /V\    Andreas Neuhaus, FaStA Informatik FH-Dortmund
 // \\    Sonnenstr. 96, D-44139 Dortmund, Tel 0231/9112-734
/(   )\    System-Administration FaStA FH-Dortmund
^^-^^
 LINUX - Don't fear the penguin