On Tuesday, Mar 11, 2003, at 09:08 Australia/Sydney, Lance Drake wrote: 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. Glad we could help! 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! Well, I for one, am still confused. At almost any level of optimisation, the machine code emitted by gcc for the above two samples should be the same... What is said in "Design of the UNIX Operating System" is true, however, as soon as your performFork() function returns, each process will have its own copy of "result". What's said in the book is that neither process can access the other processes *copy* of the variable. Like I said, glad we could help, but I don't know what fixed it :) Cheers, -- Paul Ripke Unix/OpenVMS/TSM/DBA 101 reasons why you can't find your Sysadmin: 68: It's 9AM. He/She is not working that late. -- Koos van den Hout _______________________________________________ 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.