[BusyBox] Re: Some more busybox issues...

Andreas Neuhaus andy at fasta.fh-dortmund.de
Thu Mar 15 20:53:06 UTC 2001


> > 2) linuxrc never works because applets.h uses BB_LINUXRC which is never
> > defined. fix is in one of my previous mails
> Erik recently checked in a linuxrc-related fix but I'm not sure if it was
> yours. Will you please check out the latest source and see if the problem
is
> still there?

fixed in applets.h revision 1.20

> > 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.
> This is usingthe latest cvs source and busybox compiled against uClibc:

i saw the commit announcements in the uClib mailinglist, but when running
cvs update here nothing is updated. e.g. the last mail told me:

Repository: uClibc/string
who:        andersen
time:       Thu Mar 15 14:58:26 EST 2001
Log Message:
Wow.  I'm all full of stupid mistakes today.  Fix strxfrm
 -Erik
Files:
changed:    string.c

but when doing cvs log string/string.h the last commit was on march 8th:

revision 1.7
date: 2001/03/08 07:33:05;  author: andersen;  state: Exp;  lines: +10 -0
Add strnlen

also include/string.h still contains #define index strchr... are we using
different cvs repositories? i completely checked out uClibc again, but still
i can't see your fixes.

> > 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(?).
> The  delete_initAction function accounts for the removed item. The
function is
> below with the line that handles the pointer juggling labeled as such:

> static void delete_initAction(initAction * action)
> {
> initAction *a, *b = NULL;
>
> for (a = initActionList; a; b = a, a = a->nextPtr) {
> if (a == action) {
> if (b == NULL) {
> initActionList = a->nextPtr;
> } else {
> b->nextPtr = a->nextPtr; /* <-- Pointer juggling handled here */

pointers within the list are updated correctly, there's no problem...

> }
> free(a);

this is where delete_InitAction actually frees a. (see below)

> break;
> }
> }
> }

> So, I don't think this particular case is a problem. If you find any
examples
> where linked-lists are not being managed correctly, patches are welcome.

when deleting an element while iterating, the next element is taken from a
freed element:

for (a=initActionList; a; a=a->nextPtr) {
    if (whatever) {
        // do whatever
        delete_InitAction(a);
    }
}

after delete_InitAction(a) returns, a is freed. but if the loop continues,
it'll take a->nextPtr. to prevent this, the loop should e.g. look like this:

for (a=initActionList; a; a=next) {
    next = a->nextPtr;
    if (whatever) {
        // do whatever
        delete_InitAction(a);
    }
}

deleting while iterating is always horrible...

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







More information about the busybox mailing list