Re: ...Unhappy Childhood Persists
Re: ...Unhappy Childhood Persists
- Subject: Re: ...Unhappy Childhood Persists
- From: Lance Drake <email@hidden>
- Date: Tue, 11 Mar 2003 12:56:09 -0700
Hi Jim, (et al...)
In the words of Chester A. Riley - as played by William Bendix in 'The
Life Of Riley', "What a revoltin' development this is!"
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.
You are correct, sir! - This was not the problem - although I am
especially miffed at how a light change in this area caused the failure
mode to 'move' - thus making me look silly as I announced that the
problem had been solved. For a time, the tool did not crash, but it
was not receiving any notifications and I thought, "Well, time to drill
down to the NEXT level of incompatibility". Actually, I was just lucky
it was not tripping on its own shoelaces - which were still tied
together.
Are both versions pre-bound?
I tried checking and unchecking the pre-binding box in PB. No effect.
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.
If this is what's happening (which sounds reasonable), I surely do not
know how we got headed into that 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).
The process of elimination was finally brought to bear on this effort.
Yes, there ARE other frameworks linked with the tool - so I went to the
trouble of pulling out all frameworks and code - down to the minimum
required to execute to the point it was crashing (Linked foundations
are now: CoreFoundation and IOKit - removing Carbon,
SystemConfiguration and DiskArbitration). Things appear now to be
stable enough to execute that "runLoopSource =
IONotificationPortGetRunLoopSource( sNotifyPort );" call which is where
the 'complete' version konks out.
Not having the source-code for performFork(), I can't comment on
whether it could trigger such problems.
<SEE BELOW FOR 'performFork()' CODE>
Where I am at the moment is that it looks like I will have to take the
fork/execve route - which seems unnecessary, considering the fact that
it all works fine (as is) in 10.2.4 and nobody has anything to point to
that represents a big change in the mach world from the 10.1 days. I
suppose I should say (in my best Jerry Seinfeld) "HEY!... whatever
works!", but I'd really like to find out why this is failing.
For now, your suggestion that the cause is a fallout from linking in
other frameworks seems to have the highest probability of significance.
I'll keep forging ahead with my 'process of addition' until I hit
paydirt. Film at 11...
Again, THANK YOU VERY MUCH for taking the time to consider this problem
and to offer your valuable comments.
Lance Drake
//
------------------------------------------------------------------------
--------
int performFork(void)
{
uid_t pid;
// prep parent to receive sigterm from child
signal(SIGTERM, parent_handle_sigterm);
pid = fork();
switch (pid)
{
case -1: // error
return(0);
break;
case 0: // child task
/* Set a new session for the child process. */
if (setsid() == -1)
{
//syslog(LOG_INFO, "setsid = -1, errno = %d", errno);
return 0;
}
/* run relative to the root of the filesystem, just in case. */
if (chdir("/") == -1)
{
//syslog(LOG_INFO, "chdir('/') == -1");
return 0;
}
return (1);
break;
default: // parent task = wait for signal, then exit
{
int status;
wait4(pid, (int *)&status, 0, 0);
if (WIFEXITED(status))
{
syslog(LOG_INFO, "ERROR: failed to start, exit status = %d",
WEXITSTATUS(status));
}
else
{
syslog(LOG_INFO, "ERROR: failed to start, received signal =
%d",
WTERMSIG(status));
}
}
break;
}
return(0);
}
//
------------------------------------------------------------------------
----
_______________________________________________
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.