Re: Trouble with gdb 6.6 and one particular app on FreeBSD 7.0...

[Eric Schuele <e dot schuele at computer dot org>]

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: signature.asc
Description: OpenPGP digital signature