Re: fork, dlopen, crash
Re: fork, dlopen, crash
- Subject: Re: fork, dlopen, crash
- From: Greg Parker <email@hidden>
- Date: Wed, 05 Feb 2014 13:18:25 -0800
On Feb 5, 2014, at 1:33 AM, Jim O'Connor <email@hidden> 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 email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden