[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