From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dov Grobgeld Newsgroups: gmane.emacs.bugs Subject: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU Date: Mon, 7 May 2012 08:07:44 +0300 Message-ID: References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8ff1c1661e77d504bf6b40a3 X-Trace: dough.gmane.org 1336367295 12666 80.91.229.3 (7 May 2012 05:08:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 May 2012 05:08:15 +0000 (UTC) Cc: 10580@debbugs.gnu.org To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 07 07:08:13 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SRGB8-0004YC-85 for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 May 2012 07:08:10 +0200 Original-Received: from localhost ([::1]:36263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRGB7-0003GM-AE for geb-bug-gnu-emacs@m.gmane.org; Mon, 07 May 2012 01:08:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRGB3-0003G6-W9 for bug-gnu-emacs@gnu.org; Mon, 07 May 2012 01:08:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRGB2-0007O2-4E for bug-gnu-emacs@gnu.org; Mon, 07 May 2012 01:08:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRGB1-0007Nw-UY for bug-gnu-emacs@gnu.org; Mon, 07 May 2012 01:08:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SRGCw-00062n-66 for bug-gnu-emacs@gnu.org; Mon, 07 May 2012 01:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dov Grobgeld Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 May 2012 05:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10580 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10580-submit@debbugs.gnu.org id=B10580.133636739623209 (code B ref 10580); Mon, 07 May 2012 05:10:02 +0000 Original-Received: (at 10580) by debbugs.gnu.org; 7 May 2012 05:09:56 +0000 Original-Received: from localhost ([127.0.0.1]:39018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGCp-00062H-DH for submit@debbugs.gnu.org; Mon, 07 May 2012 01:09:56 -0400 Original-Received: from mail-ob0-f172.google.com ([209.85.214.172]:44434) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRGCk-000620-S7 for 10580@debbugs.gnu.org; Mon, 07 May 2012 01:09:52 -0400 Original-Received: by obbeh20 with SMTP id eh20so7633877obb.3 for <10580@debbugs.gnu.org>; Sun, 06 May 2012 22:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sh11mRRoN7Lb4xAMpJ3ZUYi02kKb/XI3qXFnRVma42U=; b=KegM9XgwLq8xg3w0IA92wxki8kNkLmx8DGbNyZReHO9S5KKNeyz90laZ04dteg+42x tKW9YERkKWyYSM3iUZVg0KdrXKUQzrZ2mv3C3yJOTTCu17hGPOI8zgdvaje52sqEXOT0 q+UbQ6ZB+Sn6l59UScCBuXP6E+oN1X5u1ggBw5Re5S1ADzSlBl7ZYRczrXpAHyiJb91+ KJgFH77VjyarS96plGqLc7tc7SonORx18Duj3JVsidVAOiihq0j387nQEHw6W4nrqvJg XOF93TYBriZs0Uzkg83UURX/nOhk5QY7KcYi8d7iuCOGpsGBQ4FiVKqZWLLcO1vwb/Vj 4Giw== Original-Received: by 10.60.4.199 with SMTP id m7mr19526394oem.65.1336367264986; Sun, 06 May 2012 22:07:44 -0700 (PDT) Original-Received: by 10.182.60.137 with HTTP; Sun, 6 May 2012 22:07:44 -0700 (PDT) In-Reply-To: <874nrsem67.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:59830 Archived-At: --e89a8ff1c1661e77d504bf6b40a3 Content-Type: text/plain; charset=UTF-8 Hi Chong, In response to your questions. During the "100% CPU" time period, emacs still responds normally and files can be opened, etc. My gdb version is "GNU gdb (GDB) Fedora (7.2-52.fc14)". I have tried it at home as well with a later version from Fedora 16 and the result is the same. I put breakpoints at the lines that you indicated, but as you suspected, the breakpoints are only reached when I exit gdb with the "quit" command. What's next? Thanks again for looking into this. Dov On Mon, May 7, 2012 at 5:53 AM, Chong Yidong wrote: > Dov Grobgeld writes: > > > The *input/output of a.out* is empty. > > > > It seems that I was wrong about read_key_sequence(). It doesn't > > "return early". > > During this time, is Emacs responsive to user commands, i.e. does it > work normally apart from taking 100% CPU? Or is it just unresponsive? > > Also, what is your gdb version? > > Also, please set a breakpoint at process.c:4896, which should be the > line > > struct Lisp_Process *p = XPROCESS (proc); > > as well as the function exec_sentinel(). See if Emacs hits each > breakpoint, and step through it for the next several steps. In > exec_sentinel, please show the Lisp values of the `proc' and `reason' > variables (i.e. `pp proc' and `pp reason'.) > > Basically, gdb-mi.el allocates a pty and passes it to the gdb process, > which hooks the pty up to the debugged process's input/output. That's > what the "1-inferior-tty-set /dev/pts/9" gdb command does. Emacs then > listens for input/output on the pty. Recently I fixed a bug in which > Emacs would use 100% CPU due to Emacs getting an EIO error on that pty > and then spinning; this fix involved setting up a sentinel that closes > the pty when Emacs gets EIO; it's possible the fix is not working for > you, though I don't know why. The other possibility is that the program > you are debugging does something strange with its input/output stream. > > Thanks. > --e89a8ff1c1661e77d504bf6b40a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chong,
In response to your questions.

During the "100% CPU" tim= e period, emacs still responds normally and files can be opened, etc.
My gdb version is "GNU gdb (GDB) Fedora (7.2-52.fc14)". I have tr= ied it at home as well with a later version from Fedora 16 and the result i= s the same.

I put breakpoints at the lines that you indicated, but a= s you suspected, the breakpoints are only reached when I exit gdb with the = "quit" command.

What's next? Thanks again for looking into this.

Dov

=


On Mon, May 7, 2012 at 5:53 A= M, Chong Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:
> The *input/output of a.out* is empty.
>
> It seems that I was wrong about read_key_sequence(). It doesn't > "return early".

During this time, is Emacs responsive to user commands, i.e. does it<= br> work normally apart from taking 100% CPU? =C2=A0Or is it just unresponsive?=

Also, what is your gdb version?

Also, please set a breakpoint at process.c:4896, which should be the
line

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct Lisp_= Process *p =3D XPROCESS (proc);

as well as the function exec_sentinel(). =C2=A0See if Emacs hits each
breakpoint, and step through it for the next several steps. =C2=A0In
exec_sentinel, please show the Lisp values of the `proc' and `reason= 9;
variables (i.e. `pp proc' and `pp reason'.)

Basically, gdb-mi.el allocates a pty and passes it to the gdb process,
which hooks the pty up to the debugged process's input/output. =C2=A0Th= at's
what the "1-inferior-tty-set /dev/pts/9" gdb command does. =C2=A0= Emacs then
listens for input/output on the pty. =C2=A0Recently I fixed a bug in which<= br> Emacs would use 100% CPU due to Emacs getting an EIO error on that pty
and then spinning; this fix involved setting up a sentinel that closes
the pty when Emacs gets EIO; it's possible the fix is not working for you, though I don't know why. =C2=A0The other possibility is that the p= rogram
you are debugging does something strange with its input/output stream.

Thanks.

--e89a8ff1c1661e77d504bf6b40a3--