Trouble with GDB and specific app on 7.0-CURRENT....

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

Backtrace of gdb ==> gdb
#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=0xbfbfe544) at infrun.c:2892
#4 0x080ef284 in handle_inferior_event (ecs=0xbfbfe544) 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

Attachment: signature.asc
Description: OpenPGP digital signature

Relevant Pages

  • Re: Debugging STDIN/STDOUT Apps for XINETD in Eclipse
    ... How do I debug by allowing XINETD to launch my application ... and pump data into the app from the client via stdin, ... gdb allows attaching to arbitrary processes. ...
    (comp.os.linux.development.apps)
  • Re: Inject a shared library or DLL into a running process in Linux
    ... finding local variables you have to rely on debug information, ... Using gdb you could in theory look at every single bit, ... If you start tweaking the running app, like inserting your code, you ... recovery from crashes by undoing a crashed run might not be possible. ...
    (comp.os.linux.development.system)
  • Re: using database comparer to upgrade gdb?
    ... my app run an SQL script against the live database with all users out of the ... basically ran 3 update scripts in a row. ... > structure, I usually create a empty .gdb, then datapump the data from the ...
    (borland.public.delphi.thirdpartytools.general)
  • GDB failure if function is commented out. Very confusing.
    ... I have some code that runs fine under gdb. ... If I load the app up in gdb do 'b main' then try to run the program I ... never in the past has running the app twice at the same time been an ...
    (comp.unix.programmer)
  • Re: Unkillable Zombie process under 2.6.3 and 2.6.4
    ... This programs sticks gdb completly, i don't know who is to blame gdb or ... I'm trying to build a test app that can trigger the case where GDBed ... process become unkillable zombies ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)