public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 0/4] Fix PR gdb/19187 (process record over a fork causes internal error)
Date: Sun, 14 Feb 2016 18:37:00 -0000	[thread overview]
Message-ID: <1455475070-17797-1-git-send-email-palves@redhat.com> (raw)

This series fixes:

 (gdb) record
 break marker2
 Breakpoint 2 at 0x40067a: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.reverse/waitpid-reverse.c, line 30.
 (gdb) PASS: gdb.reverse/waitpid-reverse.exp: set breakpoint at marker2
 continue
 Continuing.
 /home/pedro/gdb/mygit/src/gdb/record-full.c:1720: internal-error: record_full_remove_breakpoint: removing unknown breakpoint
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)
 KFAIL: gdb.reverse/waitpid-reverse.exp: continue to breakpoint: marker2 (GDB internal error) (PRMS: gdb/19187)

The problem is that the target side can't distinguish between deleting
a breakpoint and detaching a breakpoint.

Right after a fork is detected, we detach breakpoints from the child
(detach_breakpoints), which calls into target_remove_breakpoint with
inferior_ptid pointing at the child process, but leaves the breakpoint
marked inserted (in the parent).

Since record-full.c's target_remove_breakpoint implementation doesn't
know we're detaching a breakpoint, it removes the breakpoint from its
own breakpoint table.

Then when we later remove the breakpoint from the parent, we fail that
assertion, since the breakpoint is unexpectedly not found in the
record-full.c breakpoint table.

The first three patches pass down the reason for removing the
breakpoint all the way to the target.

Patch 4 then simply makes record-full.c not delete the breakpoint from
its breakpoint table when we're detaching the breakpoint from a fork
child.

Pedro Alves (4):
  Simplify remove_breakpoint interface
  Introduce 'enum remove_bp_reason'
  Plumb enum remove_bp_reason all the way to target_remove_breakpoint
  Fix PR gdb/19187 (process record over a fork causes internal error)

 gdb/break-catch-sig.c                         |  3 +-
 gdb/break-catch-syscall.c                     |  2 +-
 gdb/breakpoint.c                              | 70 +++++++++++++--------------
 gdb/breakpoint.h                              | 14 +++++-
 gdb/corelow.c                                 | 10 +++-
 gdb/exec.c                                    | 10 +++-
 gdb/mem-break.c                               |  3 +-
 gdb/record-btrace.c                           |  6 ++-
 gdb/record-full.c                             | 15 ++++--
 gdb/remote.c                                  |  5 +-
 gdb/target-debug.h                            |  2 +
 gdb/target-delegates.c                        | 10 ++--
 gdb/target.c                                  |  5 +-
 gdb/target.h                                  |  9 ++--
 gdb/testsuite/gdb.reverse/waitpid-reverse.exp |  4 +-
 15 files changed, 105 insertions(+), 63 deletions(-)

-- 
1.9.3

             reply	other threads:[~2016-02-14 18:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-14 18:37 Pedro Alves [this message]
2016-02-14 18:37 ` [PATCH 3/4] Plumb enum remove_bp_reason all the way to target_remove_breakpoint Pedro Alves
2016-02-15  9:12   ` Yao Qi
2016-02-15 14:41     ` Pedro Alves
2016-02-14 18:37 ` [PATCH 1/4] Simplify remove_breakpoint interface Pedro Alves
2016-02-14 18:37 ` [PATCH 2/4] Introduce 'enum remove_bp_reason' Pedro Alves
2016-02-14 18:44 ` [PATCH 4/4] Fix PR gdb/19187 (process record over a fork causes internal error) Pedro Alves
2016-08-10 22:11 ` [PATCH 0/4] " Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1455475070-17797-1-git-send-email-palves@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).