• 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: GDB: Does "catch vfork" work?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDB: Does "catch vfork" work?


  • Subject: Re: GDB: Does "catch vfork" work?
  • From: Daniel Jalkut <email@hidden>
  • Date: Sat, 08 Oct 2005 10:56:43 -0400


On Oct 8, 2005, at 6:55 AM, Damien Bobillot wrote:

Daniel Jalkut wrote :

I noticed in the documentation that for vfork in particular, because it allows the child process to take over the parent's address space until exec'ing, the follow-fork may not be very helpful.

You're wrong : the child process did really not use the parent adress space. And even if it were true, gdb cannot follow both process at the same time, it must choose to follow the parent OR the child. Try to put a breakpoint just after a vfork, you'll see that gdb only break in the parent process (in the default configuration).

I'm sure I'm technically wrong in some ways, but I am going on what I've observed, and trying to make sense of it in terms of what I have read, for instance:

From http://ftp.gnu.org/gnu/Manuals/gdb-5.1.1/html_node/gdb_25.html:
       "When a child process is spawned by vfork, you cannot debug the child or parent until an exec call completes."

What I experience is that when I change the mode to "follow child," the behavior is no different. My breakpoint that should be triggered in the child process yields a Crash Reporter dialog (EXC_BREAKPOINT), while debugging carries on in the parent.

If you use fork, the whole parent memory is copied. If you use vfork, the memory is lazily copied : the system wait until it really need to make the copy, ie if both processes don't write anything in a given memory page, the system won't make the copy, but if one do write something, the system make the copy just before effectively writing things. This use the copy-on-write flag of the paged memory manager.

The man page for vfork (10.4 Tiger) doesn't imply such a polite interaction. It describes a scenario in which the child process literally takes over the parent's "memory and thread of control" until execve or exit is called.  If things really do behave as you describe, then a documentation bug report is in order, I think.

The only difference between fork and vfork is that vfork is more efficient : for the developer, even when debugging, both functions seem to work the same way.

Again I haven't observed thread following to work in this way. If you're skeptical, you could try on your own machine by attaching to SystemUIServer, setting follow-fork-mode child, and try to set a breakpoint on execve. If you get the luxury of hitting that breakpoint (and not a crash report) then I'd be very interested to determine the differences between our configurations.

Daniel

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: GDB: Does "catch vfork" work?
      • From: Damien Bobillot <email@hidden>
    • Re: GDB: Does "catch vfork" work?
      • From: Daniel Jalkut <email@hidden>
References: 
 >GDB: Does "catch vfork" work? (From: Daniel Jalkut <email@hidden>)
 >Re: GDB: Does "catch vfork" work? (From: Damien Bobillot <email@hidden>)
 >Re: GDB: Does "catch vfork" work? (From: Daniel Jalkut <email@hidden>)
 >Re: GDB: Does "catch vfork" work? (From: Damien Bobillot <email@hidden>)

  • Prev by Date: Crash log - "Backtrace not available"
  • Next by Date: Re: Crash log - "Backtrace not available"
  • Previous by thread: Re: GDB: Does "catch vfork" work?
  • Next by thread: Re: GDB: Does "catch vfork" work?
  • Index(es):
    • Date
    • Thread