David Howells > > My assumption is that execl*() need to allocate memory in order to > > construct the argv, so the're probably a big risk. execvp/execv > > _might_ be safe _if_ they use local storage for their work. But > > you never can be sure unless you know exactly the internals of your > > libc. > > Hmmm... You'd have to hope they use alloca() I think.
I keep forgetting about alloca because its use was discouraged in the old days. Has the alloca situation improved nowadays? > OTOH, the vfork() manual page _does_ explicitly say that you can use > any of the exec() family of functions, so if it doesn't work, you can > go and shout at your libc maintainer. I've just checked uClibc. It uses alloca only when a MMU is available. If there's no MMU, it falls back to mmap(). Now I'm somewhat confused. What's wrong with alloca in the vfork context? Maybe the problem is coupled with setjmp implementations of vfork? I found http://gcc.gnu.org/ml/gcc/2005-06/msg01265.html but that discusses vfork implementation. That's a totally different thing from exec* implementation since the exec* functions have their own stack frames > > > > malloc/free _can_ be safe, too _if_ _exactly_ the malloc'ed > > > > areas are freed. > > > I wouldn't agree here, since free doesn't always free, etc. > > OK, this will result in a memory leak. > Imagine doing vfork() from a multithreaded program You're right, multithreading introduces one more can of worms. > > - reap zombies (but the client should not have zombies since it > > is not allowed to call vfork again. (is this actually true?)) > Ugh. I think that's one of those "not recommended" things. You mean the double-vfrok? I'd consider this to be one of the "forbidden" things. _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
