Do you know whether the abort happens right at the start, or after the child has done all (or some) of its work? - p.s. I assume that both the parent and child are re-built using 10.1.x Peter Lovell If it helps, you'll get a SIGABRT calling abort(3) or a failed assert()ion. Alternately, "ulimit -c unlimited" and let it core - SIGABRT should coredump if default signal handlers haven't been changed. Paul Ripke If that's not the case I'd recommend installing a SIGABRT handler, brake in it with gdb, and take a look at the backtrace. To make gdb work with the subprocess, make it pause() right after the fork and then look up the pid with ps, start gdb without any arguments, and type attach <pid>. Pelle Johansson ------------------------------------------------------------------------ ----- Hi Peter, Paul and Pelle, After getting up this morning, I discovered your three VERY helpful letters in my inbox. Thanks to your input and suggestions, I believe the problem is solved. 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 When the pause was reached, the SIGABRT had already been generated and none of the syslog error messages I had deposited in the performFork function were showing via the 'tail -f /var/log/system.log' command in a separate terminal window. The only other activity that had taken place was the evaluation of the return value from the performFork function. Evidently, when the child process returned from the performFork routine, the reference to 'result' was bogus and caused the exception. Maurice J. Bach would seem to confirm this, on page 196 in 'Design Of The Unix Operating system' (Prentice Hall, 1986), where he reports that "neither process can access the variables of the other process". 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. Thank you all VERY MUCH for giving me that extra legup of information and moral support! Lance Drake _______________________________________________ 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.