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: Wed, 25 Jan 2012 11:39:25 +0200 Message-ID: References: <20253.9861.848886.122482@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8f2357ff07cc9a04b7570af8 X-Trace: dough.gmane.org 1327484390 29120 80.91.229.12 (25 Jan 2012 09:39:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 Jan 2012 09:39:50 +0000 (UTC) Cc: 10580@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 25 10:39:45 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RpzKT-0007Jw-14 for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Jan 2012 10:39:45 +0100 Original-Received: from localhost ([::1]:35556 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpzKS-0002Xh-EE for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Jan 2012 04:39:44 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:51749) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpzKQ-0002XS-9t for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2012 04:39:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpzKL-000298-Ky for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2012 04:39:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpzKL-000294-I5 for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2012 04:39:37 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1RpzKk-0005zL-E1 for bug-gnu-emacs@gnu.org; Wed, 25 Jan 2012 04:40:02 -0500 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: Wed, 25 Jan 2012 09:40: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.132748439923006 (code B ref 10580); Wed, 25 Jan 2012 09:40:02 +0000 Original-Received: (at 10580) by debbugs.gnu.org; 25 Jan 2012 09:39:59 +0000 Original-Received: from localhost ([127.0.0.1]:42610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpzKg-0005z0-JD for submit@debbugs.gnu.org; Wed, 25 Jan 2012 04:39:59 -0500 Original-Received: from mail-iy0-f172.google.com ([209.85.210.172]:61373) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpzKd-0005yn-TN for 10580@debbugs.gnu.org; Wed, 25 Jan 2012 04:39:57 -0500 Original-Received: by iagf6 with SMTP id f6so6400585iag.3 for <10580@debbugs.gnu.org>; Wed, 25 Jan 2012 01:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Z/AnWRrkPjje0GxqEbLSg5FHodgygpH0U+Meb+dZk8=; b=CSyRa9+X/ncO6vbJe8zJpMP3x1E6x7KLhdrpj7FWVosKJgHj1lzS3VfquLjs6uRrMp pIhvNCqJaFRo/16j8U/cVXc/k+5v5HRdug90qmB6CXxBPOyHtt47+Y+PvCB3l/i/Sho4 f4x59Ijn1PKY2o+TTxMxEq0dzGuayaFnLYhOQ= Original-Received: by 10.50.156.130 with SMTP id we2mr18223573igb.10.1327484365163; Wed, 25 Jan 2012 01:39:25 -0800 (PST) Original-Received: by 10.42.158.196 with HTTP; Wed, 25 Jan 2012 01:39:25 -0800 (PST) In-Reply-To: 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:55980 Archived-At: --e89a8f2357ff07cc9a04b7570af8 Content-Type: text/plain; charset=UTF-8 More tests. 1. I was mistaken in my previous email, the CPU spending was triggered before gdb-mode-hook. 2. The following command in gdb-input starts the 40s 100% CPU: (process-send-string (get-buffer-process gud-comint-buffer) (concat command "\n"))) where command="1-inferior-tty-set /dev/pts/9". Note that the command returns immediately, but some other thread apparently gets very busy. Is this enough info, or do you want me to probe deeper? On Wed, Jan 25, 2012 at 10:49, Dov Grobgeld wrote: > Here are some more tests: > > 1. It doesn't get stuck when debugging a "hello-world.c" program. Thus it > depends on the executable. > 2. Regarding toggle-debug-on-quit and C-g, it doesn't work. No backtrace > is produced and the CPU continues to be at 100%. > 3. I tried running edebug on gdb, which wasn't easy. I had to manually > first do eval-buffer on gdb-mi.el and gud.el. But in the end I managed and > found that the CPU is spend during (run-hooks 'gdb-mode-hook) . I'll try to > investigate it further in the next few days. > > Regards, > Dov > > On Wed, Jan 25, 2012 at 02:37, Glenn Morris wrote: > >> >> >> I tried again with emacs -Q and the same thing happens. To be more >> >> precise the startup time is about 40s at 100% CPU. >> >> Is this with everything you try to debug, or just certain things? >> >> Can you try M-x toggle-debug-on-quit, then interrupt Emacs with ctrl-g >> during those 40 seconds and see if you get a backtrace? >> >> Or try M-x edebug-defun on the `gdb' function, step through it, and see >> what is taking the time. >> >> Guesses: do you have a huge .gdb_history or ~/.gdbinit file? >> > > --e89a8f2357ff07cc9a04b7570af8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
More tests.
=
1. I was mistaken in my previous email, the CPU spending was triggered = before gdb-mode-hook.
2. The following command in gdb-input starts the 4= 0s 100% CPU:

=C2=A0 (process-send-string (get-buffer-process gud-comint-buffer)
= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = (concat command "\n")))

where command=3D"1-inf= erior-tty-set /dev/pts/9". Note that the command returns immediately, = but some other thread apparently gets very busy.

Is this enough info, or do you want me to probe deeper?

On Wed, Jan 25, 2012 at 10:49, Dov Grobgeld <dov.grobgeld@gmail.com<= /a>> wrote:
Here are some more tests:

1. It doesn't get stuck= when debugging a "hello-world.c" program. Thus it depends on the= executable.
2. Regarding toggle-debug-on-quit and C-g, it doesn't work. No backtrac= e is produced and the CPU continues to be at 100%.
3. I tried running edebug on gdb, which wasn't easy. I had to manually = first do eval-buffer on gdb-mi.el and gud.el. But in the end I managed and = found that the CPU is spend during (run-hooks 'gdb-mode-hook) . I'l= l try to investigate it further in the next few days.

Regards,
Dov

On Wed, Jan 25, 2012 at 02:37, Glenn Morris <= rgm@gnu.org>= wrote:

>> I tried again with emacs -Q and the same thing happens. To be more=
>> precise the startup time is about 40s at 100% CPU.

Is this with everything you try to debug, or just certain things?

Can you try M-x toggle-debug-on-quit, then interrupt Emacs with ctrl-g
during those 40 seconds and see if you get a backtrace?

Or try M-x edebug-defun on the `gdb' function, step through it, and see=
what is taking the time.

Guesses: do you have a huge .gdb_history or ~/.gdbinit file?


--e89a8f2357ff07cc9a04b7570af8--