Subject: toolchain/37061: threaded program stopped in debugger cannot be continued
To: None <toolchain-manager@netbsd.org, gnats-admin@netbsd.org,>
From: None <aaron@frye.com>
List: netbsd-bugs
Date: 10/04/2007 22:00:01
>Number:         37061
>Category:       toolchain
>Synopsis:       threaded program stopped in debugger cannot be continued
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 04 22:00:00 +0000 2007
>Originator:     Aaron J. Grier aaron@frye.com
>Release:        NetBSD 3.1_STABLE
>Organization:
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com
>Environment:
System: NetBSD skolem.unix.fryenet 3.1_STABLE NetBSD 3.1_STABLE (ADVANTECH.3) #1: Fri Sep 21 15:39:22 PDT 2007 aaron@orthanc.unix.fryenet:/var/obj/ADVANTECH.3 i386
Architecture: i386
Machine: i386

ADVANTECH is GENERIC with extra isa serial ports enabled

$ gdb --version
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf".

>Description:

on occation (roughly 20% of the time) a threaded application I am
debugging cannot be continued from the debugger after being paused to
insert breakpoints.  gdb gives the error "nbsd_thread_fetch_registers:
td_thr_getregs: thread can not answer request" and I am unable to switch
threads with the "thread" command, and "continue" fails.  at this point
the only thing I can do is quit the debugger and start over.

>How-To-Repeat:

 [invoke threaded program via gdb.  press ^T]
Program received signal SIGINFO, Information request.
 [Switching to LWP 5]
0x08101f7c in nanosleep ()
(gdb) info thread
  8 LWP 2  0x08101fd0 in msgrcv ()
  7 LWP 6  0x08101fd0 in msgrcv ()
  6 LWP 4  0x08101f7c in nanosleep ()
  5 LWP 7  0x08101f7c in nanosleep ()
  4 LWP 3  0x08101f7c in nanosleep ()
* 3 LWP 5  0x08101f7c in nanosleep ()
  2 Thread 1 ()  nbsd_thread_fetch_registers: td_thr_getregs: thread can not answer request

(gdb) break nb_soundio.c:1440
Breakpoint 2 at 0x80f9895: file lib/io/nb_soundio.c, line 1440.
(gdb) c
Continuing.
nbsd_thread_fetch_registers: td_thr_getregs: thread can not answer request

(gdb) c
Continuing.
nbsd_thread_fetch_registers: td_thr_getregs: thread can not answer request

(gdb) thread 8
nbsd_thread_fetch_registers: td_thr_getregs: thread can not answer request

(gdb) [HELP!]

>Fix:

get nbsd_thread_fetch_registers() and td_thr_getregs() in NetBSD's gdb
support code to "do the right thing" (whatever that is).

I would use NetBSD-4 or even -current, but under similar debugging
situations I get hit by kern/37004 which causes a panic.  given the
choice between restarting my debugging session and restarting the
computer, I chose the less painful option.

I have not tried a newer version of gdb under NetBSD-3.