[MacPorts] #45309: gimp2 @2.8.14 on 10.9 - doesn't load plug-ins
MacPorts
noreply at macports.org
Sun Nov 2 12:02:35 PST 2014
#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 jeremyhu@…):
> A very quick play with lldb breaking on dlclose() suggested that
dlclose() was being called in that gegl path,
Yep, I suspect that is resulting in the atfork handler getting removed
from the process, but we still have a dangling pointer to it. Show the
backtrace to see who is calling dlclose(). Assuming you have debug
symbols, it should point you to the correct line in source as well which
will be helpful.
> so the trigger in the _atfork() might be something else.
I'm not really sure what you mean by this. Can you please elaborate?
From my analysis, we essentially have:
1. gegl is dlopen()ed.
2. Something in gegl or its dependencies registers a child atfork handler.
3. Something is dlclose()d.
4. fork() is called.
5. The child side tries to call the atfork handler and crashes.
This would be expected if the registered atfork handler is inside of the
code that was dlclose()d.
Also, if you set your optimization flags to -O0, you will avoid tail call
optimizations, so we'll likely see the missing stack frames between:
{{{
frame #0: 0x00007fff92e420ff libsystem_c.dylib`pthread_atfork
frame #1: 0x00007fff92e3bfc0 libsystem_c.dylib`pthread_once +
87
frame #2: 0x00007fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&)
+ 236
}}}
which will tell us exactly what library initializer is doing the
pthread_atfork.
--
Ticket URL: <https://trac.macports.org/ticket/45309#comment:49>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list