Date: Tue, 12 May 2015 18:37:31 -0400 From: Jason Woodward <woodwardj@averesystems.com> To: John Baldwin <jhb@freebsd.org> Cc: Tijl Coosemans <tijl@freebsd.org>, freebsd-ports@freebsd.org Subject: Re: gdb in ports Message-ID: <CANybJcyOb%2BcH_hhPCU_SiojgV0hV_HCaMVdA9S-tO0ewFxDs9Q@mail.gmail.com> In-Reply-To: <4344191.kUiy0BFV7S@ralph.baldwin.cx> References: <CANybJcwyvTKFwmhpAQdKPwd42eGE_8MkiM2n-Ghf7Rfgqd1oFw@mail.gmail.com> <20150512180638.6202c711@kalimero.tijl.coosemans.org> <4344191.kUiy0BFV7S@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John,
I did a quick build with your patch along with a small tweak:
@@ -340,7 +340,7 @@ get_current_thread (void)
if (target_has_execution)
{
/* Enable thread event reporting for this thread. */
- err = td_thr_event_enable_p (th_p, 1);
+ err = td_thr_event_enable_p (&th, 1);
if (err != TD_OK)
error ("Cannot enable thread event reporting for %s: %s",
target_pid_to_str (ptid), thread_db_err_str (err));
That seems to resolve the thread reporting and thread switching issue I was
observing.
Still unsure if related... I triggered the following in fbsd_thread_wait(),
however when stepping through:
(gdb) n
[New Thread 826e07800 (LWP 101021)]
infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion
`!tp->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
info threads indicates I ended up in thread 15 if I continue anyway.
take care,
jason
On Tue, May 12, 2015 at 3:04 PM, John Baldwin <jhb@freebsd.org> wrote:
> On Tuesday, May 12, 2015 06:06:38 PM Tijl Coosemans wrote:
> > On Mon, 11 May 2015 16:21:42 -0400 Jason Woodward <
> woodwardj@averesystems.com> wrote:
> > > Hi all,
> > >
> > > I had sent this to Luca but maybe others might have an idea...
> > >
> > >
> > > I'm running into some difficulty debugging a live, multithreaded
> > > application. This seems to be the case with the 7.8.x gdbs and 7.9
> (both
> > > 9.2 and 10 release). When I attach, I see duplicates for the first
> thread:
> > >
> > > 5 Thread 817ff2c00 (LWP 100541) 0x000000080bd6286c in poll () at
> > > poll.S:3
> > > 4 Thread 80efe8c00 (LWP 100546) 0x000000080bd6286c in poll () at
> > > poll.S:3
> > > 3 Thread 80efe9000 (LWP 100878) 0x000000080bd6286c in poll () at
> > > poll.S:3
> > > * 2 Thread 80efe9400 (LWP 101124) 0x000000080bd6286c in poll () at
> > > poll.S:3
> > > * 1 Thread 80efe9400 (LWP 101124) 0x000000080bd6286c in poll () at
> > > poll.S:3
> > >
> > > Trying to select 1 or 2 always ends up selecting 2:
> > >
> > > (gdb) thread 1
> > > [Switching to thread 2 (Thread 80efe9400 (LWP 101124))]
> > > #0 0x000000080bd6286c in poll () at poll.S:3
> > > 3 in poll.S
> > > (gdb) thread 2
> > > [Switching to thread 2 (Thread 80efe9400 (LWP 101124))]
> > > #0 0x000000080bd6286c in poll () at poll.S:33 in poll.S
> > > (gdb)
> > >
> > > On top of this, when stepping through it seems threads that start and
> stop
> > > quickly have some sort of race condition that results in the thread
> > > tracking getting messed up. Sometimes I'll end up on thread 74, other
> > > times I will be on a thread that has gone away and "info threads" does
> not
> > > show me associated with any of the active threads. With 7.8.x I would
> see:
> > >
> > > Id Target Id Frame
> > > 75 Cannot find thread, Thread ID=101080, no thread to satisfy query
> > >
> > >
> > > Unsure if related, but after stepping through with 7.9, the following
> > > happens in fbsd_thread_wait():
> > >
> > > infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion
> > > `!tp->control.trap_expected' failed.
> > > A problem internal to GDB has been detected,
> > > further debugging may prove unreliable.
> > > Quit this debugging session? (y or n) y
> > >
> > > This is a bug, please report it. For instructions, see:
> > > <http://www.gnu.org/software/gdb/bugs/>.
> > >
> > > infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion
> > > `!tp->control.trap_expected' failed.
> > > A problem internal to GDB has been detected,further debugging may prove
> > > unreliable.
> > > Create a core file of GDB? (y or n) n
> >
> > CC jhb. Maybe he can help.
>
> So one of the changes made after fbsd-threads.c had been first ported to
> GDB 7
> was to remove a call to 'init_thread_list()' in fbsd_thread_activate().
> There
> is an open PR against 7.9 where the solution I've come up with for now is
> to
> put that back for cores to ignore the threads that GDB creates as LWPs
> when it
> walks the core dump notes. I've included that diff below. You could try
> using
> that for live debugging, but I think that isn't the real solution.
> Instead,
> when we attach threads we should be doing a change_ptid() to change the
> "main"
> thread to be a thread instead of a process.
>
> Try this:
>
> Index: fbsd-threads.c
> ===================================================================
> --- fbsd-threads.c (revision 385904)
> +++ fbsd-threads.c (working copy)
> @@ -320,16 +320,36 @@ get_current_thread (void)
> lwp = get_current_lwp (proc_handle.pid);
> tmp = BUILD_LWP (lwp, proc_handle.pid);
> ptid = thread_from_lwp (tmp, &th, &ti);
> - if (in_thread_list (inferior_ptid) )
> + if (in_thread_list (inferior_ptid))
> {
> - struct thread_info * ti_inf = inferior_thread();
> - ti_inf->ptid = ptid;
> + struct private_thread_info *private;
> + struct thread_info *tp;
> + td_err_e err;
> +
> + thread_change_ptid (inferior_ptid, ptid);
> +
> + /* Add thread with info */
> + private = xcalloc(1, sizeof(struct private_thread_info));
> + gdb_assert(private != NULL);
> + // Thread name is assigned when printed
> +
> + tp = find_thread_ptid (ptid);
> + gdb_assert(tp->private == NULL);
> + tp->private = private;
> + tp->private_dtor = free_private_thread_info;
> + if (target_has_execution)
> + {
> + /* Enable thread event reporting for this thread. */
> + err = td_thr_event_enable_p (th_p, 1);
> + if (err != TD_OK)
> + error ("Cannot enable thread event reporting for %s: %s",
> + target_pid_to_str (ptid), thread_db_err_str (err));
> + }
> }
> - if (!in_thread_list (ptid))
> + else if (!in_thread_list (ptid))
> {
> attach_thread (ptid, &th, &ti, 1);
> }
> - inferior_ptid = ptid;
> }
>
> static CORE_ADDR
> @@ -441,8 +461,10 @@ fbsd_thread_activate (void)
> fbsd_thread_active = 1;
> if (target_has_execution)
> enable_thread_event_reporting ();
> + else
> + init_thread_list ();
> + get_current_thread ();
> fbsd_thread_update_thread_list (NULL);
> - get_current_thread ();
> }
>
> static void
> @@ -667,13 +689,11 @@ attach_thread (ptid_t ptid, const td_thrhandle_t *
> if (!in_thread_list (ptid))
> {
> /* Add thread with info */
> - private = xmalloc(sizeof(struct private_thread_info));
> + private = xcalloc(1, sizeof(struct private_thread_info));
> gdb_assert(private != NULL);
> // Thread name is assigned when printed
> - memset(private, 0, sizeof(struct private_thread_info));
>
> tp = add_thread_with_info(ptid, private);
> - tp->private = private;
> tp->private_dtor = free_private_thread_info;
> }
>
>
> --
> John Baldwin
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANybJcyOb%2BcH_hhPCU_SiojgV0hV_HCaMVdA9S-tO0ewFxDs9Q>