Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

OS X Leopard error.

Help
2007-11-20
2013-04-22
  • David Bentley
    David Bentley
    2007-11-20

    I just installed 7.10 by .dmg and when I execute mged I get the following:

    Initializing and backgrounding, please wait...The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
    Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

    Anyone seen this before?

    I am running an Intel Core Duo 1.83 with 2gb RAM, and Mac OS X 10.5.1

    Thanks in advance,

    David

     
    • David Bentley
      David Bentley
      2007-11-21

      I found this in the OS X developer release notes:

      CoreFoundation and fork()
      Due to the behavior of fork(), CoreFoundation cannot be used on the child-side of fork(). If you fork(), you must follow that with an exec*() call of some sort, and you should not use CoreFoundation APIs within the child, before the exec*(). The applies to all higher-level APIs which use CoreFoundation, and since you cannot know what those higher-level APIs are doing, and whether they are using CoreFoundation APIs, you should not use any higher-level APIs either. This includes use of the daemon() function.

      Additionally, per POSIX, only async-cancel-safe functions are safe to use on the child side of fork(), so even use of lower-level libSystem/BSD/UNIX APIs should be kept to a minimum, and ideally to only async-cancel-safe functions.

      This has always been true, and there have been notes made of this on various Cocoa developer mailling lists in the past. But CoreFoundation is taking some stronger measures now to "enforce" this limitation, so we thought it would be worthwhile to add a release note to call this out as well. A message is written to stderr when something uses API which is definitely known not to be safe in CoreFoundation after fork(). If file descriptor 2 has been closed, however, you will get no message or notice, which is too bad. We tried to make processes terminate in a very recognizable way, and did for a while and that was very handy, but backwards binary compatibility prevented us from doing so.

       
      • Sean Morrison
        Sean Morrison
        2007-11-23

        David,

        Thanks for the report and for the follow-up information.  I'd heard someone else using 10.5 had run into this but since I don't have it in hand myself, I've not yet had a chance to investigate the cause.  My guess is that the error is related to mged's automatic detachment and then Tcl making CoreFoundation calls.  We don't make any CoreFoundation calls directly, so Tcl would likely be the cause.

        Something to try, assuming that message it gave you isn't simply an annoyance and actually impacts run-time operability is to run mged with the -f flag, i.e. /usr/brlcad/bin/mged -f, which keeps mged in the foreground.  That avoids the forking behavior and should make the message go away.  Interested in hearing if that helps.

        Cheers!
        Sean

         
    • David Bentley
      David Bentley
      2007-11-23

      Sean,
      That worked!  Thanks for the help and especially since you responded on Thanksgiving.

      -David

       
    • Armin
      Armin
      2008-03-13

      Thanks for the advice in this thread. The same error occurred on my new Leopard machine, and the -f flag solved the problem.

      Cheers,
      Armin