[MacPorts] #45309: gimp2 @2.8.14 on 10.9 - doesn't load plug-ins

[MacPorts]

#45309: gimp2 @2.8.14 on 10.9 - doesn't load plug-ins
---------------------------+----------------------
  Reporter:  and.damore@…  |      Owner:  devans@…
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  gimp2         |
---------------------------+----------------------

Comment (by macports@…):

 I ran into this same problem on Mavericks.  After spending a while trying
 reactivating older ports (eg, older gtk2, older  glib2 2.40) -- which
 didn't seem to solve the problem, and involved lots of rebuilding things
 depending on them, I started looking at the glib2 source.

 In particular the verbose error output says:
 {{{
 Error spawning command line `launchctl getenv
 DBUS_LAUNCHD_SESSION_BUS_SOCKET': Child process killed by signal 11
 Dynamic session lookup supported but failed: launchctl terminated
 abnormally without any error message
 Not enough memory
 }}}

 which implies that maybe it's a memory allocation being failed.  So I
 started following the glib2 call chain for running a process, from the
 launchctl example above (seemed easier than trying to find where the
 plugins get loaded, since I imagine they're going through a common glib2
 function.

 The call path seems to be:
 0.  g_spawn_command_line_sync()
 0.  g_spawn_sync()
 0.  fork_exec_with_pipes()
 0.  do_exec()
 0.  Optionally: (* child_setup)(user_data)
 0.  g_execute()

 and AFAICT in g_execute() (in glib/gspawn.c) it looks like there is a
 memory allocation performed if the thing being run does not have a full
 path (around line 1721, glib 2.42):
 {{{
       freeme = name = g_malloc (pathlen + len + 1);
 }}}
 which is consistent with the command line printed out (running bare
 launchctl).

 Memory allocations are one of those things which are typically on the "do
 not do between fork() and exec()."  Although sometimes the rules for
 single threaded and multi-threaded applications are different about some
 of these things.  (Hard to be sure if that will allocate memory or not,
 since it goes through all the glib2 memory wrappers too.)

 So just as another option to consider for, eg, pthread atfork related
 things.

 Possibly if someone figures out when it last worked (which is why I was
 trying downgrading glib2/gtk2/etc) then it'll be more obvious why it has
 stopped working.

 Ewen

-- 
Ticket URL: <https://trac.macports.org/ticket/45309#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X