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 | 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.