This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[COMMIT PATCH] Fix regressions caused by thread-specific breakpoint deletion. (was: Re: [PATCH] PR gdb/11568 - delete thread-specific breakpoints on thread exit)
- From: Pedro Alves <palves at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: Muhammad Waqas <mwaqas at codesourcery dot com>
- Date: Thu, 19 Sep 2013 15:48:24 +0100
- Subject: [COMMIT PATCH] Fix regressions caused by thread-specific breakpoint deletion. (was: Re: [PATCH] PR gdb/11568 - delete thread-specific breakpoints on thread exit)
- Authentication-results: sourceware.org; auth=none
- References: <521CF7D0 dot 5040801 at redhat dot com> <1377692710-2885-1-git-send-email-mwaqas at codesourcery dot com> <5224C0EB dot 3000503 at redhat dot com> <5224C238 dot 2060106 at redhat dot com> <871u4ykmgq dot fsf at fleche dot redhat dot com> <5238AF1A dot 4070000 at redhat dot com>
The recent change to make GDB auto-delete thread-specific breakpoints
when the corresponding thread is deleted
(https://sourceware.org/ml/gdb-patches/2013-09/msg00038.html) caused
gdb.base/nextoverexit.exp to regress.
Breakpoint 1, main () at .../gdb/testsuite/gdb.base/nextoverexit.c:21
21 exit (0);
(gdb) next
[Inferior 1 (process 25208) exited normally]
Thread-specific breakpoint -5 deleted - thread 1 is gone.
Thread-specific breakpoint -6 deleted - thread 1 is gone.
Thread-specific breakpoint -7 deleted - thread 1 is gone.
Thread-specific breakpoint 0 deleted - thread 1 is gone.
(gdb) FAIL: gdb.base/nextoverexit.exp: next over exit (the program exited)
We shouldn't be seeing this for internal or momentary breakpoints. In
fact, we shouldn't even be trying to delete them, as whatever created
them will take care or it, and therefore it's dangerous to delete them
behind the creator's back.
I thought it'd still be good to tag thread-specific internal/momentary
breakpoints such that we'll no longer try to keep them insert in the
target, as they'll cause stops and thread hops in other threads, so I
tried disabling them instead. That caused a problem when following a
child fork, and detaching from the parent, as we try to reset the
step-resume etc. breakpoints to the new child's thread
(breakpoint_re_set_thread), after the parent thread is already gone
(and the breakpoints are marked disabled). I fixed that by
re-enabling internal/momentary breakpoints there, but, that didn't
feel super safe either (maybe we'd need a new flag in struct
breakpoint instead, to tag the thread-specific breakpoint as "not to
be inserted"). It felt like I was heading down a design rat hole,
and, other things will usually delete internal/momentary breakpoints
soon enough, so I left that little optimization for some other day.
So, internal/momentary breakpoints are no longer deleted/disabled at
all, and we end up with a one-liner fix.
Tested on x86_64 Fedora 17.
gdb/
2013-09-19 Pedro Alves <palves@redhat.com>
* breakpoint.c (remove_threaded_breakpoints): Skip non-user
breakpoints.
---
gdb/breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 734dfd6..c132e24 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -2938,7 +2938,7 @@ remove_threaded_breakpoints (struct thread_info *tp, int silent)
ALL_BREAKPOINTS_SAFE (b, b_tmp)
{
- if (b->thread == tp->num)
+ if (b->thread == tp->num && user_breakpoint_p (b))
{
b->disposition = disp_del_at_next_stop;
--
1.7.11.7