On Monday, March 10, 2003, at 05:08 PM, Lance Drake wrote: It appears the SIGABRT was caused by an invalid reference to a local stack var in the main function which was accepting the value returned by my call to the fork activities routine. The original code was: int result; ... result = performFork(); // create long-lived version of this process if(0 == result) // parent returning?... goto ExitPath; // say goodbye to parent pause(); // <-- inserted for debug, thanks to Pelle Johansson ... The code was changed to: if(0 == performFork()) // parent returning?... goto ExitPath; // say goodbye to parent // pause(); // <-- inserted for debug, thanks to Pelle Johansson For whatever reason, MacOSX 10.2 seems to be far more forgiving on this point as this tool has never crashed in that environment. As others have said, these are moral equivalents. If one fails, the other should as well. Are both versions pre-bound? Often, people look at the effect of trivial changes like this and forget that the execution life-cycle of a process is radically changed whether it is pre-bound or not. In fact, a common dyld failure mode on 10.1 is to call abort() when it detects that it has painted itself in a corner. Does your application link against any Apple-specific frameworks other than libSystem? There should be quite a few references in the archives about "No other Apple frameworks, other than libSystem, can be combined with fork() and expect consistent results." You must immediately call exec() or _exit() (with only signal-safe calls between these and the fork() call). Not having the source-code for performFork(), I can't comment on whether it could trigger such problems. --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.