Re: Happy child (w/10.2), gets SIGABRT (w/10.1)
Re: Happy child (w/10.2), gets SIGABRT (w/10.1)
- Subject: Re: Happy child (w/10.2), gets SIGABRT (w/10.1)
- From: Paul Ripke <email@hidden>
- Date: Tue, 11 Mar 2003 09:45:30 +1100
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 | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.