* Trouble with gdb 6.6 and one particular app on FreeBSD 7.0...
@ 2007-09-30 4:02 Eric Schuele
2007-09-30 6:20 ` Kip Macy
0 siblings, 1 reply; 3+ messages in thread
From: Eric Schuele @ 2007-09-30 4:02 UTC (permalink / raw)
To: gdb
[-- Attachment #1: Type: text/plain, Size: 7213 bytes --]
Hello,
I have a particular app that I am unable to debug using gdb. When I
attach to the app and continue it, gdb begins to take up 100% of my cpu.
It will do this forever (well longer than I've ever waited).
I am able to debug this particular app on my 6.2-STABLE machine. And I
can debug other apps on my 7.0 machine. I've tried both gdb 6.1 and gdb
6.6 on my 7.0 machine with no change in behavior.
I first thought maybe I had done something odd when rebuilding my
kernel/world? But I've built a second 7.0 machine and stuck with the
GENERIC kernel and I have the same results.
Most times I can not break into the app once I have continued it. I
have attached gdb to gdb to watch what it is doing and it appears to
give me a few different backtraces, though it is always one of maybe
three traces. [See below for bt of gdb attached to gdb, unfortunately
its not the same bt I was seeing... but may offer some insight?]
Has anyone seen behavior like this? What else can I provide that might
help diagnose this?
--
Regards,
Eric
Several backtraces of gdb ==> gdb in same session...
Program received signal SIGINT, Interrupt.
0x0805241b in find_pc_sect_section (pc=681465567, section=0x0)
at objfiles.c:762
762 in objfiles.c
(gdb) bt
#0 0x0805241b in find_pc_sect_section (pc=681465567, section=0x0)
at objfiles.c:762
#1 0x0805249a in find_pc_section (pc=681465567) at objfiles.c:776
#2 0x080aa087 in find_pc_partial_function (pc=681465567, name=0xbfbfe590,
address=0xbfbfe588, endaddr=0xbfbfe58c) at blockframe.c:189
#3 0x080eed68 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:1776
#4 0x080ed63e in wait_for_inferior () at infrun.c:1009
#5 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
step=0) at infrun.c:827
#6 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
at infcmd.c:642
#7 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:62
#8 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:1666
#9 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
#10 0x080feadf in command_handler (command=0x2890c080 "c") at
event-top.c:519
#11 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
event-top.c:804
#12 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
#13 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
at event-top.c:179
#14 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
at event-top.c:432
---Type <return> to continue, or q <return> to quit---
#15 0x080fd860 in handle_file_event (event_file_desc=0) at event-loop.c:730
#16 0x080fd090 in process_event () at event-loop.c:343
#17 0x080fd0d9 in gdb_do_one_event (data=0x0) at event-loop.c:380
#18 0x080fa46c in catch_errors (func=0x80fd0a5 <gdb_do_one_event>,
func_args=0x0, errstring=0x8262c9e "", mask=6) at exceptions.c:515
#19 0x0809b11b in tui_command_loop (data=0x0) at
.././gdb/tui/tui-interp.c:151
#20 0x080fa95d in current_interp_command_loop () at interps.c:278
#21 0x0804eec7 in captured_command_loop (data=0x0) at .././gdb/main.c:101
#22 0x080fa46c in catch_errors (func=0x804eebc <captured_command_loop>,
func_args=0x0, errstring=0x824f0e6 "", mask=6) at exceptions.c:515
#23 0x0804fd3c in captured_main (data=0xbfbfead4) at .././gdb/main.c:826
#24 0x080fa46c in catch_errors (func=0x804eefd <captured_main>,
func_args=0xbfbfead4, errstring=0x824f0e6 "", mask=6) at
exceptions.c:515
#25 0x0804fdad in gdb_main (args=0xbfbfead4) at .././gdb/main.c:835
#26 0x0804eeb1 in main (argc=3, argv=0xbfbfeb28) at gdb.c:44
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x080b80e1 in set_register_cached (regnum=15, state=0) at regcache.c:434
434 regcache.c: No such file or directory.
in regcache.c
(gdb) bt
#0 0x080b80e1 in set_register_cached (regnum=15, state=0) at regcache.c:434
#1 0x080b8186 in registers_changed () at regcache.c:472
#2 0x080f063c in prepare_to_wait (ecs=0xbfbfe574) at infrun.c:2917
#3 0x080f05f8 in keep_going (ecs=0xbfbfe574) at infrun.c:2895
#4 0x080ef284 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:2021
#5 0x080ed63e in wait_for_inferior () at infrun.c:1009
#6 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
step=0) at infrun.c:827
#7 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
at infcmd.c:642
#8 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:62
#9 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:1666
#10 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
#11 0x080feadf in command_handler (command=0x2890c080 "c") at
event-top.c:519
#12 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
event-top.c:804
#13 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
#14 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
at event-top.c:179
#15 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
at event-top.c:432
#16 0x080fd860 in handle_file_event (event_file_desc=0) at event-loop.c:730
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x28784c0b in ?? () from /lib/libc.so.7
(gdb) bt
#0 0x28784c0b in ?? () from /lib/libc.so.7
#1 0xbfbfe2b0 in ?? ()
#2 0x28980c20 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00003f80 in ?? ()
#5 0x00000000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x2874cbbb in ptrace () from /lib/libc.so.7
(gdb) bt
#0 0x2874cbbb in ptrace () from /lib/libc.so.7
#1 0x08068b42 in i386fbsd_resume (ptid={pid = -1, lwp = 0, tid = 0},
step=0,
signal=TARGET_SIGNAL_CHLD) at i386fbsd-nat.c:76
#2 0x080ed0de in resume (step=0, sig=TARGET_SIGNAL_CHLD) at infrun.c:626
#3 0x080f05ed in keep_going (ecs=0xbfbfe574) at infrun.c:2892
#4 0x080ef284 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:2021
#5 0x080ed63e in wait_for_inferior () at infrun.c:1009
#6 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
step=0) at infrun.c:827
#7 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
at infcmd.c:642
#8 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:62
#9 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
at .././gdb/cli/cli-decode.c:1666
#10 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
#11 0x080feadf in command_handler (command=0x2890c080 "c") at
event-top.c:519
#12 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
event-top.c:804
#13 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
#14 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
at event-top.c:179
#15 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
at event-top.c:432
---Type <return> to continue, or q <return> to quit---
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Trouble with gdb 6.6 and one particular app on FreeBSD 7.0...
2007-09-30 4:02 Trouble with gdb 6.6 and one particular app on FreeBSD 7.0 Eric Schuele
@ 2007-09-30 6:20 ` Kip Macy
2007-10-01 3:41 ` Eric Schuele
0 siblings, 1 reply; 3+ messages in thread
From: Kip Macy @ 2007-09-30 6:20 UTC (permalink / raw)
To: Eric Schuele; +Cc: gdb
On 9/29/07, Eric Schuele <e.schuele@computer.org> wrote:
> Hello,
>
> I have a particular app that I am unable to debug using gdb. When I
> attach to the app and continue it, gdb begins to take up 100% of my cpu.
> It will do this forever (well longer than I've ever waited).
>
> I am able to debug this particular app on my 6.2-STABLE machine. And I
> can debug other apps on my 7.0 machine. I've tried both gdb 6.1 and gdb
> 6.6 on my 7.0 machine with no change in behavior.
>
> I first thought maybe I had done something odd when rebuilding my
> kernel/world? But I've built a second 7.0 machine and stuck with the
> GENERIC kernel and I have the same results.
>
> Most times I can not break into the app once I have continued it. I
> have attached gdb to gdb to watch what it is doing and it appears to
> give me a few different backtraces, though it is always one of maybe
> three traces. [See below for bt of gdb attached to gdb, unfortunately
> its not the same bt I was seeing... but may offer some insight?]
>
> Has anyone seen behavior like this? What else can I provide that might
> help diagnose this?
This sounds more like a ptrace bug / change in behavior. My first
guess is that the behavior of ptrace has changed and that gdb is
expecting a different return code from the one that it is getting. Is
your app threaded? The default threading library has changed. Can you
produce a small test case that causes this behavior?
Thanks.
-Kip
>
> --
> Regards,
> Eric
>
> Several backtraces of gdb ==> gdb in same session...
>
> Program received signal SIGINT, Interrupt.
> 0x0805241b in find_pc_sect_section (pc=681465567, section=0x0)
> at objfiles.c:762
> 762 in objfiles.c
> (gdb) bt
> #0 0x0805241b in find_pc_sect_section (pc=681465567, section=0x0)
> at objfiles.c:762
> #1 0x0805249a in find_pc_section (pc=681465567) at objfiles.c:776
> #2 0x080aa087 in find_pc_partial_function (pc=681465567, name=0xbfbfe590,
> address=0xbfbfe588, endaddr=0xbfbfe58c) at blockframe.c:189
> #3 0x080eed68 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:1776
> #4 0x080ed63e in wait_for_inferior () at infrun.c:1009
> #5 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
> step=0) at infrun.c:827
> #6 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
> at infcmd.c:642
> #7 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:62
> #8 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:1666
> #9 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
> #10 0x080feadf in command_handler (command=0x2890c080 "c") at
> event-top.c:519
> #11 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
> event-top.c:804
> #12 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
> #13 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
> at event-top.c:179
> #14 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
> at event-top.c:432
> ---Type <return> to continue, or q <return> to quit---
> #15 0x080fd860 in handle_file_event (event_file_desc=0) at event-loop.c:730
> #16 0x080fd090 in process_event () at event-loop.c:343
> #17 0x080fd0d9 in gdb_do_one_event (data=0x0) at event-loop.c:380
> #18 0x080fa46c in catch_errors (func=0x80fd0a5 <gdb_do_one_event>,
> func_args=0x0, errstring=0x8262c9e "", mask=6) at exceptions.c:515
> #19 0x0809b11b in tui_command_loop (data=0x0) at
> .././gdb/tui/tui-interp.c:151
> #20 0x080fa95d in current_interp_command_loop () at interps.c:278
> #21 0x0804eec7 in captured_command_loop (data=0x0) at .././gdb/main.c:101
> #22 0x080fa46c in catch_errors (func=0x804eebc <captured_command_loop>,
> func_args=0x0, errstring=0x824f0e6 "", mask=6) at exceptions.c:515
> #23 0x0804fd3c in captured_main (data=0xbfbfead4) at .././gdb/main.c:826
> #24 0x080fa46c in catch_errors (func=0x804eefd <captured_main>,
> func_args=0xbfbfead4, errstring=0x824f0e6 "", mask=6) at
> exceptions.c:515
> #25 0x0804fdad in gdb_main (args=0xbfbfead4) at .././gdb/main.c:835
> #26 0x0804eeb1 in main (argc=3, argv=0xbfbfeb28) at gdb.c:44
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x080b80e1 in set_register_cached (regnum=15, state=0) at regcache.c:434
> 434 regcache.c: No such file or directory.
> in regcache.c
> (gdb) bt
> #0 0x080b80e1 in set_register_cached (regnum=15, state=0) at regcache.c:434
> #1 0x080b8186 in registers_changed () at regcache.c:472
> #2 0x080f063c in prepare_to_wait (ecs=0xbfbfe574) at infrun.c:2917
> #3 0x080f05f8 in keep_going (ecs=0xbfbfe574) at infrun.c:2895
> #4 0x080ef284 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:2021
> #5 0x080ed63e in wait_for_inferior () at infrun.c:1009
> #6 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
> step=0) at infrun.c:827
> #7 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
> at infcmd.c:642
> #8 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:62
> #9 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:1666
> #10 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
> #11 0x080feadf in command_handler (command=0x2890c080 "c") at
> event-top.c:519
> #12 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
> event-top.c:804
> #13 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
> #14 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
> at event-top.c:179
> #15 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
> at event-top.c:432
> #16 0x080fd860 in handle_file_event (event_file_desc=0) at event-loop.c:730
> ---Type <return> to continue, or q <return> to quit---q
> Quit
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x28784c0b in ?? () from /lib/libc.so.7
> (gdb) bt
> #0 0x28784c0b in ?? () from /lib/libc.so.7
> #1 0xbfbfe2b0 in ?? ()
> #2 0x28980c20 in ?? ()
> #3 0x00000004 in ?? ()
> #4 0x00003f80 in ?? ()
> #5 0x00000000 in ?? ()
> (gdb) c
> Continuing.
> ^C
> Program received signal SIGINT, Interrupt.
> 0x2874cbbb in ptrace () from /lib/libc.so.7
> (gdb) bt
> #0 0x2874cbbb in ptrace () from /lib/libc.so.7
> #1 0x08068b42 in i386fbsd_resume (ptid={pid = -1, lwp = 0, tid = 0},
> step=0,
> signal=TARGET_SIGNAL_CHLD) at i386fbsd-nat.c:76
> #2 0x080ed0de in resume (step=0, sig=TARGET_SIGNAL_CHLD) at infrun.c:626
> #3 0x080f05ed in keep_going (ecs=0xbfbfe574) at infrun.c:2892
> #4 0x080ef284 in handle_inferior_event (ecs=0xbfbfe574) at infrun.c:2021
> #5 0x080ed63e in wait_for_inferior () at infrun.c:1009
> #6 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
> step=0) at infrun.c:827
> #7 0x080ea249 in continue_command (proc_count_exp=0x0, from_tty=1)
> at infcmd.c:642
> #8 0x0808082b in do_cfunc (c=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:62
> #9 0x08082e6d in cmd_func (cmd=0x28977190, args=0x0, from_tty=1)
> at .././gdb/cli/cli-decode.c:1666
> #10 0x08054cbd in execute_command (p=0x2890c081 "", from_tty=1) at top.c:455
> #11 0x080feadf in command_handler (command=0x2890c080 "c") at
> event-top.c:519
> #12 0x080ff307 in command_line_handler (rl=0x2895b112 "c") at
> event-top.c:804
> #13 0x28319826 in rl_callback_read_char () from /lib/libreadline.so.7
> #14 0x080fe1cf in rl_callback_read_char_wrapper (client_data=0x0)
> at event-top.c:179
> #15 0x080fe96f in stdin_event_handler (error=0, client_data=0x0)
> at event-top.c:432
> ---Type <return> to continue, or q <return> to quit---
>
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Trouble with gdb 6.6 and one particular app on FreeBSD 7.0...
2007-09-30 6:20 ` Kip Macy
@ 2007-10-01 3:41 ` Eric Schuele
0 siblings, 0 replies; 3+ messages in thread
From: Eric Schuele @ 2007-10-01 3:41 UTC (permalink / raw)
To: Kip Macy, gdb
[-- Attachment #1: Type: text/plain, Size: 3856 bytes --]
On 09/29/2007 23:02, Kip Macy wrote:
> On 9/29/07, Eric Schuele <e.schuele@computer.org> wrote:
>> Hello,
>>
>> I have a particular app that I am unable to debug using gdb. When I
>> attach to the app and continue it, gdb begins to take up 100% of my cpu.
>> It will do this forever (well longer than I've ever waited).
>>
>> I am able to debug this particular app on my 6.2-STABLE machine. And I
>> can debug other apps on my 7.0 machine. I've tried both gdb 6.1 and gdb
>> 6.6 on my 7.0 machine with no change in behavior.
>>
>> I first thought maybe I had done something odd when rebuilding my
>> kernel/world? But I've built a second 7.0 machine and stuck with the
>> GENERIC kernel and I have the same results.
>>
>> Most times I can not break into the app once I have continued it. I
>> have attached gdb to gdb to watch what it is doing and it appears to
>> give me a few different backtraces, though it is always one of maybe
>> three traces. [See below for bt of gdb attached to gdb, unfortunately
>> its not the same bt I was seeing... but may offer some insight?]
>>
>> Has anyone seen behavior like this? What else can I provide that might
>> help diagnose this?
>
> This sounds more like a ptrace bug / change in behavior. My first
> guess is that the behavior of ptrace has changed and that gdb is
> expecting a different return code from the one that it is getting.
Sounds reasonable. As it frequently breaks within ptrace.
> Is
> your app threaded?
Well, it makes use of shared objects which are. But the app itself has
no threading code.
> The default threading library has changed. Can you
> produce a small test case that causes this behavior?
Well... not sure yet how to go about doing that (yet). Here's what I
have. I can walk the code to a particular line using gdb. This
particular line is a call to a func in a library, which does little more
than add a callback to a linked list. Now this very call was issued
several lines prior to now with no issue (several times in fact).
However on this instance, if I attempt to step into the func (which I
could do previously), gdb never gains control again.
Here is a bt of gdb attached to the gdb which has never returned from
attempting to step into the above mentioned function.
#0 0x2874cbbb in ptrace () from /lib/libc.so.7
#1 0x08068b42 in i386fbsd_resume (ptid={pid = -1, lwp = 0, tid = 0},
step=0,
signal=TARGET_SIGNAL_CHLD) at i386fbsd-nat.c:76
#2 0x080ed0de in resume (step=0, sig=TARGET_SIGNAL_CHLD) at infrun.c:626
#3 0x080f05ed in keep_going (ecs=0xbfbfb594) at infrun.c:2892
#4 0x080ef284 in handle_inferior_event (ecs=0xbfbfb594) at infrun.c:2021
#5 0x080ed63e in wait_for_inferior () at infrun.c:1009
#6 0x080ed46a in proceed (addr=4294967295, siggnal=TARGET_SIGNAL_DEFAULT,
step=1) at infrun.c:827
#7 0x080ea50c in step_1 (skip_subroutines=0, single_inst=0,
count_string=0x0)
at infcmd.c:761
#8 0x080ea26c in step_command (count_string=0x0, from_tty=0) at
infcmd.c:650
#9 0x0808082b in do_cfunc (c=0x2897bef0, args=0x0, from_tty=0)
at .././gdb/cli/cli-decode.c:62
#10 0x08082e6d in cmd_func (cmd=0x2897bef0, args=0x0, from_tty=0)
at .././gdb/cli/cli-decode.c:1666
#11 0x08095520 in gdbtk_call_command (cmdblk=0x2897bef0, arg=0x0,
from_tty=0)
at .././gdb/gdbtk/generic/gdbtk-hooks.c:539
#12 0x08054c9d in execute_command (p=0x29e5f944 "", from_tty=0) at top.c:453
#13 0x08090fc6 in gdb_immediate_command (clientData=0x8090ed6,
interp=0x2894ce00, objc=2, objv=0x289b303c)
at .././gdb/gdbtk/generic/gdbtk-cmds.c:749
#14 0x08090972 in wrapped_call (opaque_args=0xbfbfb848)
---Type <return> to continue, or q <return> to quit---
[snip other backtraces]
Thanks for your interest and assistance.
--
Regards,
Eric
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-10-01 3:41 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-30 4:02 Trouble with gdb 6.6 and one particular app on FreeBSD 7.0 Eric Schuele
2007-09-30 6:20 ` Kip Macy
2007-10-01 3:41 ` Eric Schuele
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox