[gccsdk] fork/exec problems
beeb at woosh.co.nz
Fri May 11 18:37:06 PDT 2012
In message <b102448d52.Jo at hobbes.bass-software.com>
John Tytgat <John.Tytgat at aaug.net> wrote:
> In message <e420538c52.beeb at ron1954.woosh.co.nz>
> Ron <beeb at woosh.co.nz> wrote:
> > I dont know if unixlib's version of fork() does this "copy on
> > write" or not, or any other details,
> As I mentioned in another mail, UnixLib's implementation is rather
> simple here. It just temporary moves parent out of the way (but in
> the same application workspace), runs the child and then you have
> the return to the parent.
> > just that fork()/exec has been
> > causing unstability in the past a (few months ago) and now with
> > latest svn upgrades stops program completely at the fork()/exec.
> > The earlier situation was erratic and I think would be difficult
> > to build a small test case to show it happening. It possibly is
> > only happening while running a largish program.
> > I am getting a better picture of things now, for example I know
> > now that it is fork()/exec causing unstability, and there are
> > obvious advantages to using vfork()/exec in maybe all cases.
> IMHO you're drawing the wrong conclusion. fork+exec on its own is not
> causing any unstability by definition. It is just for your case hitting a
> currently unknown problem. That might be in your program, use, setup
> and/or in UnixLib. As long there isn't attempt made to drill down to the
> real issue, we're unable to draw any valid conclusion at all.
Taking into consideration your point that fork() is probably not buggy,
and the fact that vfork() is working OK, and that the two methods use
the memory allocation differently, I will try some variations in
The second day I used vfork()/exec I run into sigsev error at the point,
similar to the latest fork()/exec, but it turned out I needed a larger
wimpslot. That was puzzling because I was performing the same operation
on the same files as the previous day.
I won't rule out the possibility of running the binary in a different
manner, for example the running of Tar from an Obey file that is run
from a Taskwindow compared to running it more directly, and I have run
it from a wimptask also. Checking for results on my RiscPc 3.7 should
do things differently too.
It is less frantic trying things out now that I have a bulletproof
version using vfork()/exec (save for the guessing game for a wimpslot).
One thing that was not very manageable by using fork()/exec was the
incrementing of memory used by about 740K every time it was used.
So a program that can run in say, 1280K using vfork() alternatively
would swallow up over 32MB with 50 or so calls to fork()/exec
(speculation based on what happened in the Task display)
It is possible that tar is not closing the script file each time it
is run from the fork(0)/exec and not releasing the memory.
Thanks for your tips.
More information about the gcc