Re: kern/51420 (gdb hangs waiting for traced threaded child under compat_netbsd32)

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR kern/51420; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51420 (gdb hangs waiting for traced threaded child under compat_netbsd32)
Date: Sat, 12 Nov 2016 12:15:21 +0100

 It does not hang any more, but the child does fail to run still:
 
 > gdb dig
 GNU gdb (GDB) 7.10.1
 [..]
 (gdb) run
 Starting program: /usr/bin/dig 
 warning: GDB can't find the start of the function at 0x77d59eb8.
 
     GDB is unable to find the start of the function at 0x77d59eb8
 and thus can't determine the size of that function's stack frame.
 This means that GDB may be unable to access that stack frame, or
 the frames below it.
     This problem is most likely caused by an invalid program counter or
 stack pointer.
     However, if you think GDB should simply search farther back
 from 0x77d59eb8 for code which looks like the beginning of a
 function, you can increase the range of the search using the `set
 heuristic-fence-post' command.
 
 Program received signal SIGTRAP, Trace/breakpoint trap.
 0x77d59eb8 in ?? ()
 (gdb) bt
 #0  0x77d59eb8 in ?? ()
 
 
 and the console logs:
 
 trap: pid 110(dig): sig 5: cause=0x24 epc=0x787d26f0 va=0x787d26f0
 registers:
 [ 0]=00000000 [ 1]=00000000 [ 2]=00000000 [ 3]=787cb85c
 [ 4]=00000003 [ 5]=7fff6b68 [ 6]=00000000 [ 7]=00000000
 [ 8]=00000001 [ 9]=00000000 [10]=00000006 [11]=77d00248
 [12]=00000001 [13]=00000000 [14]=00000000 [15]=787fc500
 [16]=787f47e0 [17]=7fff6c30 [18]=787f0000 [19]=0003b0f0
 [20]=787f4b90 [21]=787f47bc [22]=00000000 [23]=787f4b90
 [24]=0000012a [25]=787d26f0 [26]=00000000 [27]=00000000
 [28]=787fc500 [29]=7fff6b68 [30]=787cc000 [31]=787d5344
 trap: pid 110(dig): sig 5: cause=0x24 epc=0x787d5344 va=0x787d5344
 registers:
 [ 0]=00000000 [ 1]=00000000 [ 2]=00000000 [ 3]=787cb85c
 [ 4]=00000003 [ 5]=7fff6b68 [ 6]=00000000 [ 7]=00000000
 [ 8]=00000001 [ 9]=00000000 [10]=00000006 [11]=77d00248
 [12]=00000001 [13]=00000000 [14]=00000000 [15]=787fc500
 [16]=787f47e0 [17]=7fff6c30 [18]=787f0000 [19]=0003b0f0
 [20]=787f4b90 [21]=787f47bc [22]=00000000 [23]=787f4b90
 [24]=0000012a [25]=787d26f0 [26]=00000000 [27]=00000000
 [28]=787fc500 [29]=7fff6b68 [30]=787cc000 [31]=787d5344
 trap: pid 110(dig): sig 5: cause=0x24 epc=0x787d26f0 va=0x787d26f0
 registers:
 [ 0]=00000000 [ 1]=00000000 [ 2]=00000001 [ 3]=ffffffffffffffff
 [ 4]=787f4a08 [ 5]=00000000 [ 6]=ffffffff80000001 [ 7]=00000000
 [ 8]=7fff6920 [ 9]=77b981d4 [10]=780e4a38 [11]=00000078
 [12]=00000001 [13]=00000000 [14]=00000000 [15]=787fc500
 [16]=77b9f148 [17]=00000001 [18]=00000001 [19]=787d26f0
 [20]=787f4ce8 [21]=787c3008 [22]=00000000 [23]=00000008
 [24]=0000106c [25]=787d26f0 [26]=00000000 [27]=00000000
 [28]=787fc500 [29]=7fff6958 [30]=00000000 [31]=787d636c
 
 
 But I can kill the process and exit gdb properly:
 
 (gdb) kill
 Kill the program being debugged? (y or n) y
 (gdb) quit
 > dig
 
 ; <<>> DiG 9.10.4-P3 <<>>
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4234
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27
 
 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags:; udp: 4096
 ;; QUESTION SECTION:
 ;.                              IN      NS
 
 ;; ANSWER SECTION:
 .                       109337  IN      NS      a.root-servers.net.
 .                       109337  IN      NS      j.root-servers.net.
 .                       109337  IN      NS      c.root-servers.net.
 [..]
 
 
 Martin