From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32162 invoked by alias); 1 Oct 2007 03:41:25 -0000 Received: (qmail 32153 invoked by uid 22791); 1 Oct 2007 03:41:23 -0000 X-Spam-Check-By: sourceware.org Received: from smtpauth13.prod.mesa1.secureserver.net (HELO smtpauth13.prod.mesa1.secureserver.net) (64.202.165.37) by sourceware.org (qpsmtpd/0.31) with SMTP; Mon, 01 Oct 2007 03:41:21 +0000 Received: (qmail 27557 invoked from network); 1 Oct 2007 03:41:19 -0000 Received: from unknown (96.226.25.79) by smtpauth13.prod.mesa1.secureserver.net (64.202.165.37) with ESMTP; 01 Oct 2007 03:41:19 -0000 Message-ID: <47006C5E.1070006@computer.org> Date: Mon, 01 Oct 2007 03:41:00 -0000 From: Eric Schuele User-Agent: Thunderbird 2.0.0.6 (X11/20070921) MIME-Version: 1.0 To: Kip Macy , gdb@sourceware.org Subject: Re: Trouble with gdb 6.6 and one particular app on FreeBSD 7.0... References: <46FF1E8B.1040402@computer.org> In-Reply-To: OpenPGP: url=http://www.ravenlock.us/files/pub_schuele.pgp Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA3C3C0639773C520D45A13D5" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00003.txt.bz2 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA3C3C0639773C520D45A13D5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 3848 On 09/29/2007 23:02, Kip Macy wrote: > On 9/29/07, Eric Schuele 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? >=20 > 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.=20 Sounds reasonable. As it frequently breaks within ptrace. > Is > your app threaded?=20 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=3D{pid =3D -1, lwp =3D 0, tid =3D 0= }, step=3D0, signal=3DTARGET_SIGNAL_CHLD) at i386fbsd-nat.c:76 #2 0x080ed0de in resume (step=3D0, sig=3DTARGET_SIGNAL_CHLD) at infrun.c:6= 26 #3 0x080f05ed in keep_going (ecs=3D0xbfbfb594) at infrun.c:2892 #4 0x080ef284 in handle_inferior_event (ecs=3D0xbfbfb594) at infrun.c:2021 #5 0x080ed63e in wait_for_inferior () at infrun.c:1009 #6 0x080ed46a in proceed (addr=3D4294967295, siggnal=3DTARGET_SIGNAL_DEFAU= LT, step=3D1) at infrun.c:827 #7 0x080ea50c in step_1 (skip_subroutines=3D0, single_inst=3D0, count_string=3D0x0) at infcmd.c:761 #8 0x080ea26c in step_command (count_string=3D0x0, from_tty=3D0) at infcmd.c:650 #9 0x0808082b in do_cfunc (c=3D0x2897bef0, args=3D0x0, from_tty=3D0) at .././gdb/cli/cli-decode.c:62 #10 0x08082e6d in cmd_func (cmd=3D0x2897bef0, args=3D0x0, from_tty=3D0) at .././gdb/cli/cli-decode.c:1666 #11 0x08095520 in gdbtk_call_command (cmdblk=3D0x2897bef0, arg=3D0x0, from_tty=3D0) at .././gdb/gdbtk/generic/gdbtk-hooks.c:539 #12 0x08054c9d in execute_command (p=3D0x29e5f944 "", from_tty=3D0) at top.= c:453 #13 0x08090fc6 in gdb_immediate_command (clientData=3D0x8090ed6, interp=3D0x2894ce00, objc=3D2, objv=3D0x289b303c) at .././gdb/gdbtk/generic/gdbtk-cmds.c:749 #14 0x08090972 in wrapped_call (opaque_args=3D0xbfbfb848) ---Type to continue, or q to quit--- [snip other backtraces] Thanks for your interest and assistance. --=20 Regards, Eric --------------enigA3C3C0639773C520D45A13D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 187 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHAGxengSDRM3IXUoRAiXWAJ96Vwk6tybEZGNrI/RfqD/5JELtTQCgy/xz JhK/KmFqN1i2KWM9ybxxVnU= =KXEc -----END PGP SIGNATURE----- --------------enigA3C3C0639773C520D45A13D5--