[llvm-bugs] [Bug 30983] New: Breakpoint in child process (after fork) hangs the child

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Nov 11 02:00:48 PST 2016


https://llvm.org/bugs/show_bug.cgi?id=30983

            Bug ID: 30983
           Summary: Breakpoint in child process (after fork) hangs the
                    child
           Product: lldb
           Version: unspecified
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: simon.kagstrom at netinsight.net
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I'm afraid I'm using LLDB on OSX Sierra, not built from source.

I'm experiencing a problem when setting breakpoints which are hit by a child
process after a fork. A simple example to trigger the problem can be found
below.

If I set a breakpoint on the "printf("In child\n");" statement, the child
process will hit it without reporting to the parent, and then simply hang there
(so that the printout is never seen).

I assume this is because the breakpoints aren't being reported back to LLDB, as
in Bug 17972. If follow-fork mode won't be implemented, then at least perhaps
breakpoints can be cleared for the child?

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/user.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(int argc, const char *argv[])
{
  pid_t child;

  child = fork();
  if (child < 0)
    {
      printf("Error\n");
    }
  else if (child == 0)
    {
      printf("In child\n"); // Breakpoint here is bad news!
    }
  else
    {
      int status;
      printf("In parent, child %d\n", child);

      wait(&status);
    }

  return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161111/de2ac04d/attachment-0001.html>


More information about the llvm-bugs mailing list