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

 Some thoughts on debugging this, in case someone has more time:
 immediately after the fork() point there are two processes, the parent and
 the child.  Whatever is going wrong is clearly in the child process, and
 it seems to fail quickly enough that it's tricky to get a debugger to
 attach:

 *   "LANG=C lldb gimp-2.8" in one window

 *   "b fork", then "run", wait for breakpoint to hit

 *   "LANG=C lldb" in another window, and "process attach -w -n gimp-2.8"
 to get it to attach to the next gimp-2.8 process that appears

 *   "c" in the first window, so the fork() happens

 but AFAICT the child exits (due to the error we're trying to debug) before
 the lldb has time to do anything meaningful with it.

 I did try installing gdb, for "set follow-fork-mode child" but even after
 doing the code signing dance it appears OS X doesn't have kernel support
 needed for "follow-fork-mode" to work automatically, so gdb has to be used
 in basically the same way, which also doesn't have time to work.  Plus gdb
 didn't seem to find any symbols, where as lldb at least had function
 names, so I think gdb is a deadend.

 So... I think the only meaningful way to debug this would be a code change
 in the **child** side of the fork() (ie, in glib's
 fork_exec_with_pipes()), which made the child wait a lot longer before it
 did something that caused it to exit again (ie, immediately at the top of
 the child part of the function).  Say, sleeping for 5 seconds.  Which
 would allow time to attach the debugger to the child (as above), break out
 to the debugger, and set some more breakpoints, then continue/step through
 the child side of the code.

 It'll take a bit of time to change the glib code, recompile/install, and
 step through, but at least we'd know which particular bit of the child
 code is failing which would, eg, make it feasible to report upstream more
 specifically.  I'm unlikely to have time to do this before late next week,
 but will have a go late next week if no one else has time to try before
 then.

 Ewen

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