• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: fork, dlopen, crash
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >__CF120290 (From: "Jim O'Connor" <email@hidden>)
 >fork, dlopen, crash (From: "Jim O'Connor" <email@hidden>)

  • Prev by Date: Re: fork, dlopen, crash
  • Next by Date: Document Architecture: saving or renaming a document overtop of an existing, open document
  • Previous by thread: Re: fork, dlopen, crash
  • Next by thread: Re: fork, dlopen, crash
  • Index(es):
    • Date
    • Thread