On Feb 5, 2014, at 1:33 AM, Jim O'Connor <jocon...@orderndev.com> wrote:
> If I’m running from Xcode 4.6.3 on Mavericks...
>
> daemon(0,0); // no matter the values of the args
> dlopen(full path, RTLD_NOW);
>
> gives me this:
>
> 0 dyld 0x8fe0d652
> gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info const*) + 1
> 1 ??? 0000000000 0 + 0
> 2 dyld 0x8fe046ae
> dyld::notifyBatchPartial(dyld_image_states, bool, char const*
> (*)(dyld_image_states, unsigned int, dyld_image_info const*)) + 761
> 3 dyld 0x8fe021d1
> dyld::notifyBatch(dyld_image_states) + 23
> 4 dyld 0x8fe0e6d1
> ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool,
> ImageLoader::RPathChain const&) + 103
> 5 dyld 0x8fe04905 dyld::link(ImageLoader*,
> bool, bool, ImageLoader::RPathChain const&) + 176
> 6 dyld 0x8fe0c1ef dlopen + 459
> 7 libdyld.dylib 0x9a692b84 dlopen + 70
>
>
> Switching to dlopen first fixes the problem. However the code that does the
> dlopen() isn’t fork safe so it really needs to come after the daemon call.
>
> Everything is okay if I run from the command line.
>
> It is inconvenient to not be able to run from the debugger...
This sounds like a bug in the debugger. lldb sets a breakpoint on
gdb_image_notifier() in order to catch libraries being loaded. After daemon()
you are a new process. Apparently the debugger did not attach to the new
process but incorrectly left its breakpoint active there. When the breakpoint
is hit again without the debugger waiting to handle it, the process crashes.
You should file a bug report. lldb should be able to follow the child, or clean
up the breakpoints if it does not.
The only workaround I can think of is to ensure the debugger is not attached
when you call daemon().
1. Write an infinite loop after the daemon call:
volatile int go = 0;
while (!go) sleep(1);
2. Set a breakpoint before the daemon() call.
3. At the breakpoint, detach the debugger. The process should continue, call
daemon(), and spin in the loop.
4. Attach the debugger to the new daemon process.
5. Break out of the loop by using the debugger to set go=1.
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
