From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
To: gdb@sourceware.org
Subject: How to avoid stepping inside libpthread
Date: Wed, 11 Jul 2007 06:18:00 -0000 [thread overview]
Message-ID: <20070711.151820.55513191.nemoto@toshiba-tops.co.jp> (raw)
[-- Attachment #1: Type: Text/Plain, Size: 2999 bytes --]
When I keep typing "next" command in debug session, gdb might try to
do single stepping inside libpthread. And on atomic operations (LL/SC
loop, as I'm using Linux/MIPS), the single stepping never ends.
GNU gdb 6.6
...
This GDB was configured as "mips-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b func # thread's entry point
Breakpoint 1 at 0x400700: file foo.c, line 6.
(gdb) run
Starting program: ./foo
[Thread debugging using libthread_db enabled]
[New Thread 715939536 (LWP 756)]
[New Thread 726549712 (LWP 759)]
[Switching to Thread 726549712 (LWP 759)]
Breakpoint 1, func (arg=0x0) at foo.c:6
6 return arg; /* last statement of the thread */
(gdb) n
7 }
(gdb)
0x2ab0ae88 in start_thread () from /lib/libpthread.so.0
(gdb)
Single stepping until exit from function start_thread,
which has no line number information.
The gdb stops.
There is a LL/SC loop (atomic_decrement_and_test(&__nptl_nthreads))
after the 0x2ab0ae88 in start_thread(), so it is not wonder the single
stepping never ends (SC always fail due to a breakpoint exception).
Are there any way to avoid falling into such situations? Only I can
do is be careful to not enter "next" command inside libpthread?
Once I fell into this situation, C-c can might stop the gdb, but
sometimes it cause internal-error.
../../gdb-6.6/gdb/linux-nat.c:1333: internal-error: wait_lwp: Assertion `lp->status == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
I have not investigated this error further.
And current gdb snapshot (6.6.50.20070711) behaves differently.
GNU gdb 6.6.50.20070711
...
This GDB was configured as "mips-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) b func
Breakpoint 1 at 0x400700: file foo.c, line 6.
(gdb) run
Starting program: ./foo
warning: Can not parse XML target description; XML support was disabled at compile time
[New LWP 754]
[Switching to LWP 754]
Breakpoint 1, func (arg=0x0) at foo.c:6
6 return arg; /* last statement of the thread */
(gdb)
7 }
(gdb)
warning: GDB can't find the start of the function at 0x2ab0ae88.
GDB is unable to find the start of the function at 0x2ab0ae88
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 0x2ab0ae88 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.
warning: GDB can't find the start of the function at 0x2ab0ae87.
0x2ab0ae88 in ?? ()
(gdb) n
Cannot find bounds of current function
It seems current gdb snapshot can not find symbol for 0x2ab0ae88. Is
this behavior intentional?
---
Atsushi Nemoto
[-- Attachment #2: foo.c --]
[-- Type: Text/Plain, Size: 228 bytes --]
#include <stdio.h>
#include <pthread.h>
void *func(void *arg)
{
return arg;
}
int main(int argc, char **argv)
{
pthread_t id;
pthread_create(&id, NULL, func, NULL);
pthread_join(id, NULL);
printf("done\n");
return 0;
}
next reply other threads:[~2007-07-11 6:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-11 6:18 Atsushi Nemoto [this message]
2007-07-11 9:00 ` Andreas Schwab
2007-07-12 2:15 ` Atsushi Nemoto
2007-07-12 6:31 ` Atsushi Nemoto
2007-07-12 11:10 ` Daniel Jacobowitz
2007-07-13 7:04 ` Atsushi Nemoto
2007-09-26 21:06 ` Daniel Jacobowitz
2007-07-11 11:40 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070711.151820.55513191.nemoto@toshiba-tops.co.jp \
--to=anemo@mba.ocn.ne.jp \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox