[gccsdk] fork/exec problems

Ron 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.
> John.

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 
this dept.
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.
Ron M.



More information about the gcc mailing list