This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Disable thread specific breakpoints when thread dies
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: andrew dot stubbs at st dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 13 Jan 2006 21:11:35 +0100 (CET)
- Subject: Re: [PATCH] Disable thread specific breakpoints when thread dies
- References: <43723446.7000903@st.com> <20051113184515.GG3599@nevyn.them.org> <437875B0.4000007@st.com> <20051114155659.GA25717@nevyn.them.org> <437A19DE.6040905@st.com> <437B47A1.4040705@st.com> <20051117034811.GB3057@nevyn.them.org> <437CA66B.9060201@st.com> <20060112162659.GA16141@nevyn.them.org> <43C7E466.9080703@st.com>
> Date: Fri, 13 Jan 2006 17:33:26 +0000
> From: Andrew STUBBS <andrew.stubbs@st.com>
>
> Daniel Jacobowitz wrote:
> >>> You shouldn't need to use the target method here. Does valid_thread_id
> >>> work?
> >>>
> >>> Also, please remember the space before opening parentheses.
> >> The thread still seems to have a valid ID after it has died. You can
> >> even do 'b 8 t 4' after the program has exited. It does give an error
> >> for threads which never existed though.
> >
> > Why does that happen? It is presumably a bug.
> >
>
> I have looked into this. The problem is that the threads are only
> deleted from the table when 'info threads' is used. The target method
> works because that queries the target, not GDB's internal state, and
> always gets the right answer (at least in our target interface).
>
> I am happy, therefore, that the attached patch, with valid_thread_id(),
> is correct, and will work once this other problem has been solved (or if
> the user types 'info threads').
>
> OK to commit?
Sorry, but I don't think we should commit a patch that's just papering
over some other more serious problem, perhaps perhaps if there's some
pressing need to do so.
Mark