[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@…):

 After spending a bunch of time rebuilding glib2 with various print debugs
 (and some sleep(5) calls), I take it back.  As best I can tell the child
 is not making it to the next line of code in
 gspawn.c:fork_exec_with_pipes() -- a print immediately after the fork()
 runs in the parent, but not obviously in the child.  With the patch I was
 trying (I'll attach in a minute), output looks like this:

 {{{
 ewen at ashram:~$ gimp-2.8
 About to fork in fork_exec_with_pipes()
 Immediately after fork in fork_exec_with_pipes(), pid=66894
 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
 About to fork in fork_exec_with_pipes()
 Immediately after fork in fork_exec_with_pipes(), pid=66901

 (gimp-2.8:66893): LibGimpBase-WARNING **: gimp-2.8: gimp_wire_read():
 error
 }}}

 The pid=NNNNN is the return value from fork(), so the fact we're getting a
 non-zero value means that print is coming from the parent process (if it
 was from the child process it'd say "pid=0").  I believe the
 gimp_wire_read() is just a result of the child suddenly going away, and
 thus the pipe to it being closed.

 In the hope of getting **some** idea of what was happening in the child, I
 found [http://dtrace.org/blogs/brendan/2011/10/10/top-10-dtrace-scripts-
 for-mac-os-x/ some hints on dtrace on OS X] and tried using "dtruss" to
 see what was happening, viz:

 {{{
 lldb /opt/local/bin/gimp-2.8
 b main
 run
 }}}

 to start a gimp-2.8 process and pause it, then in another window:

 {{{
 sudo dtruss -f -n gimp-2.8 2>&1
 }}}

 to trace (and follow children) of the "gimp-2.8" processes, and then "c"
 in the "lldb" session.

 After letting the gimp-2.8 process run for a little bit, I had a look for
 fork() calls in the dtruss() output.  The most interesting bit is this:

 {{{
 66945/0x224bb8:  fork()          = 0 0
 66945/0x224bb8:  thread_selfid(0x7FFF7536B310, 0x7FFF87915E2E, 0x1)
 = 2247608 0
 66945/0x224bb8:  bsdthread_register(0x7FFF8AB13FBC, 0x7FFF8AB13FAC,
 0x2000)              = -1 Err#22
 }}}

 and:

 {{{
 66947/0x224ccd:  fork()          = 0 0
 66947/0x224ccd:  thread_selfid(0x7FFF7536B310, 0x7FFF87915E2E, 0x1)
 = 2247885 0
 66947/0x224ccd:  bsdthread_register(0x7FFF8AB13FBC, 0x7FFF8AB13FAC,
 0x2000)              = -1 Err#22
 }}}

 and so on.  It appears basically all of the children follow that pattern
 of three syscalls -- a return from fork(), a thread_selfid(), and then a
 bsdthread_register() which then appears to fail.  I suspect that's not
 good, but I've been able to find out very little about what
 bsdthread_register() actually does.  (I'll also attach that full dtruss
 output in a minute.)

 The only other time those PIDs are seen is when the parent wait4()
 collects the return code.  So they're definitely vanishing pretty soon
 after that.

 At this point I think we either (a) need a much smaller reproducible test
 case or (b) someone who knows more about the internals of OS X (or both).
 It's possible there's some other _atfork() style handler causing havoc,
 but off hand I don't know other ways those might be registered -- and if
 it'd cause bsdthread_register() to fail.

 Ewen

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