Re[2]: Happy child (w/10.2), gets SIGABRT (w/10.1)
Re[2]: Happy child (w/10.2), gets SIGABRT (w/10.1)
- Subject: Re[2]: Happy child (w/10.2), gets SIGABRT (w/10.1)
- From: Lance Drake <email@hidden>
- Date: Mon, 10 Mar 2003 15:08:19 -0700
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 | 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.