From unknown Fri Jun 20 07:15:46 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#10580 <10580@debbugs.gnu.org> To: bug#10580 <10580@debbugs.gnu.org> Subject: Status: 24.0.92; gdb initialization takes more than one minute at 100% CPU Reply-To: bug#10580 <10580@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:15:46 +0000 retitle 10580 24.0.92; gdb initialization takes more than one minute at 100= % CPU reassign 10580 emacs submitter 10580 Dov Grobgeld severity 10580 important tag 10580 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 22 12:54:33 2012 Received: (at submit) by debbugs.gnu.org; 22 Jan 2012 17:54:33 +0000 Received: from localhost ([127.0.0.1]:40183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rp1cd-0001UO-L6 for submit@debbugs.gnu.org; Sun, 22 Jan 2012 12:54:33 -0500 Received: from eggs.gnu.org ([140.186.70.92]:56312) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rowkd-0002kV-4G for submit@debbugs.gnu.org; Sun, 22 Jan 2012 07:42:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RowkM-0005iF-Os for submit@debbugs.gnu.org; Sun, 22 Jan 2012 07:42:13 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:33820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RowkM-0005i9-N9 for submit@debbugs.gnu.org; Sun, 22 Jan 2012 07:42:10 -0500 Received: from eggs.gnu.org ([140.186.70.92]:41564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RowkK-0007Va-4V for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2012 07:42:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RowkH-0005hL-5X for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2012 07:42:08 -0500 Received: from mail-iy0-f169.google.com ([209.85.210.169]:38259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RowkG-0005h8-Px for bug-gnu-emacs@gnu.org; Sun, 22 Jan 2012 07:42:05 -0500 Received: by iadj38 with SMTP id j38so4158788iad.0 for ; Sun, 22 Jan 2012 04:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=roitHJf5pJIyjJ8+X1eQlOOfN+TvPCTvZv4jaPjQCv0=; b=vyYJA8Bj66qfudnhTijbWWo60dCKAhpSq/Kc8TARm/4vqI53TqQLStTUeGegJxSKhF kkEHcZGJpHGFYAtioCsZc14OPhAwRCNZLk8dWr1lt6bk7VXVqNJB6TUmwVGU7F7FXnbQ C9WPFqysWH6tRzbj4+0F02ca6G2ItuhhY5O3Q= MIME-Version: 1.0 Received: by 10.50.236.67 with SMTP id us3mr6329799igc.14.1327236122016; Sun, 22 Jan 2012 04:42:02 -0800 (PST) Received: by 10.42.158.196 with HTTP; Sun, 22 Jan 2012 04:42:01 -0800 (PST) Date: Sun, 22 Jan 2012 14:42:01 +0200 Message-ID: Subject: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -3.4 (---) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Sun, 22 Jan 2012 12:54:29 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgement at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': ------------------------------ When trying to running gdb on my process, emacs gets stuck for more than one minutes while the CPU load is at 100%. Running gdb from the shell buffer yields the following response: > gdb -i=mi SolarJet =thread-group-added,id="i1" ~"GNU gdb (GDB) Fedora (7.2-52.fc14)\n" ~"Copyright (C) 2010 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later \nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n" ~"This GDB was configured as \"i686-redhat-linux-gnu\".\nFor bug reporting instructions, please see:\n" ~"...\n" ~"Reading symbols from /mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/qt/BinLinux32/SolarJet..." ~"done.\n" (gdb) But as I said, running it by Meta-x gdb SolarJet yields the following message, and then emacs gets stuck for more than one minute: Reading symbols from /mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/qt/BinLinux32/SolarJet...done. Note that in earlier versions of emacs (23.2.1), the gdb prompt was received immediately after the done message has been shown. --------------------------------- If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. For information about debugging Emacs, please read the file /usr/local/public-dev/share/emacs/24.0.92/etc/DEBUG. In GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.22.0) of 2012-01-22 on dovg32 Windowing system distributor `Fedora Project', version 11.0.10905000 configured using `configure '--prefix=/usr/local/public-dev'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.utf8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Dired by name Minor modes in effect: show-paren-mode: t shell-dirtrack-mode: t csv-field-index-mode: t xmsi-mode: t diff-auto-refine-mode: t delete-selection-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: Recent messages: No previous history command The program is not being run. Quit [2 times] Mark set Error during redisplay: (void-variable font-lock-shell-prompt-face) /mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/qt Error during redisplay: (void-variable font-lock-shell-prompt-face) [2 times] Error during redisplay: (void-variable font-lock-shell-cmd-args-face) [14 times] Error during redisplay: (void-variable font-lock-shell-prompt-face) gud-query-cmdline: Command attempted to use minibuffer while in minibuffer Load-path shadows: /home/dov/.config/emacs/longlines hides /usr/local/public-dev/share/emacs/24.0.92/lisp/longlines /home/dov/.config/emacs/cedet/common/ezimage hides /usr/local/public-dev/share/emacs/24.0.92/lisp/ezimage /home/dov/.config/emacs/cedet/speedbar/sb-image hides /usr/local/public-dev/share/emacs/24.0.92/lisp/sb-image /home/dov/.config/emacs/cedet/speedbar/dframe hides /usr/local/public-dev/share/emacs/24.0.92/lisp/dframe /home/dov/.config/emacs/cedet/speedbar/speedbar hides /usr/local/public-dev/share/emacs/24.0.92/lisp/speedbar /home/dov/.config/emacs/octave-inf hides /usr/local/public-dev/share/emacs/24.0.92/lisp/progmodes/octave-inf /home/dov/.config/emacs/gdb-mi hides /usr/local/public-dev/share/emacs/24.0.92/lisp/progmodes/gdb-mi /home/dov/.config/emacs/octave-mod hides /usr/local/public-dev/share/emacs/24.0.92/lisp/progmodes/octave-mod /home/dov/.config/emacs/compile hides /usr/local/public-dev/share/emacs/24.0.92/lisp/progmodes/compile /home/dov/.config/emacs/org-mode/ob-org hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-org /home/dov/.config/emacs/org-mode/org-attach hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-attach /home/dov/.config/emacs/org-mode/ob-lilypond hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-lilypond /home/dov/.config/emacs/org-mode/org-remember hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-remember /home/dov/.config/emacs/org-mode/org-bbdb hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-bbdb /home/dov/.config/emacs/org-mode/org-mhe hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mhe /home/dov/.config/emacs/org-mode/org-src hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-src /home/dov/.config/emacs/org-mode/org-wl hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-wl /home/dov/.config/emacs/org-mode/ob-table hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-table /home/dov/.config/emacs/org-mode/ob-comint hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-comint /home/dov/.config/emacs/org-mode/ob-mscgen hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-mscgen /home/dov/.config/emacs/org-mode/org-ascii hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-ascii /home/dov/.config/emacs/org-mode/org-freemind hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-freemind /home/dov/.config/emacs/org-mode/org-w3m hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-w3m /home/dov/.config/emacs/org-mode/org-compat hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-compat /home/dov/.config/emacs/org-mode/ob-screen hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-screen /home/dov/.config/emacs/org-mode/ob-matlab hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-matlab /home/dov/.config/emacs/org-mode/ob-keys hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-keys /home/dov/.config/emacs/org-mode/ob-asymptote hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-asymptote /home/dov/.config/emacs/org-mode/ob-emacs-lisp hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-emacs-lisp /home/dov/.config/emacs/org-mode/org-archive hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-archive /home/dov/.config/emacs/org-mode/org-docbook hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-docbook /home/dov/.config/emacs/org-mode/org-list hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-list /home/dov/.config/emacs/org-mode/ob-ditaa hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-ditaa /home/dov/.config/emacs/org-mode/ob-C hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-C /home/dov/.config/emacs/org-mode/org-exp hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-exp /home/dov/.config/emacs/org-mode/ob-exp hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-exp /home/dov/.config/emacs/org-mode/ob-ocaml hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-ocaml /home/dov/.config/emacs/org-mode/org-faces hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-faces /home/dov/.config/emacs/org-mode/org-entities hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-entities /home/dov/.config/emacs/org-mode/ob-perl hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-perl /home/dov/.config/emacs/org-mode/org-footnote hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-footnote /home/dov/.config/emacs/org-mode/org-info hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-info /home/dov/.config/emacs/org-mode/org-exp-blocks hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-exp-blocks /home/dov/.config/emacs/org-mode/org-inlinetask hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-inlinetask /home/dov/.config/emacs/org-mode/ob-ruby hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-ruby /home/dov/.config/emacs/org-mode/ob-eval hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-eval /home/dov/.config/emacs/org-mode/org-colview hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-colview /home/dov/.config/emacs/org-mode/org-agenda hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-agenda /home/dov/.config/emacs/org-mode/org-beamer hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-beamer /home/dov/.config/emacs/org-mode/ob-lisp hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-lisp /home/dov/.config/emacs/org-mode/org-mks hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mks /home/dov/.config/emacs/org-mode/ob-latex hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-latex /home/dov/.config/emacs/org-mode/org-html hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-html /home/dov/.config/emacs/org-mode/org-jsinfo hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-jsinfo /home/dov/.config/emacs/org-mode/ob-sh hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-sh /home/dov/.config/emacs/org-mode/org-timer hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-timer /home/dov/.config/emacs/org-mode/ob-python hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-python /home/dov/.config/emacs/org-mode/ob hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob /home/dov/.config/emacs/org-mode/ob-octave hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-octave /home/dov/.config/emacs/org-mode/org-xoxo hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-xoxo /home/dov/.config/emacs/org-mode/org-crypt hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-crypt /home/dov/.config/emacs/org-mode/ob-scheme hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-scheme /home/dov/.config/emacs/org-mode/org-plot hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-plot /home/dov/.config/emacs/org-mode/org-icalendar hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-icalendar /home/dov/.config/emacs/org-mode/ob-gnuplot hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-gnuplot /home/dov/.config/emacs/org-mode/ob-dot hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-dot /home/dov/.config/emacs/org-mode/org-datetree hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-datetree /home/dov/.config/emacs/org-mode/ob-css hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-css /home/dov/.config/emacs/org-mode/ob-plantuml hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-plantuml /home/dov/.config/emacs/org-mode/org-rmail hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-rmail /home/dov/.config/emacs/org-mode/org-habit hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-habit /home/dov/.config/emacs/org-mode/org-mouse hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mouse /home/dov/.config/emacs/org-mode/org-latex hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-latex /home/dov/.config/emacs/org-mode/org-ctags hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-ctags /home/dov/.config/emacs/org-mode/ob-sqlite hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-sqlite /home/dov/.config/emacs/org-mode/ob-clojure hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-clojure /home/dov/.config/emacs/org-mode/org-taskjuggler hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-taskjuggler /home/dov/.config/emacs/org-mode/org-capture hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-capture /home/dov/.config/emacs/org-mode/org-mew hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mew /home/dov/.config/emacs/org-mode/org-vm hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-vm /home/dov/.config/emacs/org-mode/org-id hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-id /home/dov/.config/emacs/org-mode/org-publish hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-publish /home/dov/.config/emacs/org-mode/org-indent hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-indent /home/dov/.config/emacs/org-mode/ob-sass hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-sass /home/dov/.config/emacs/org-mode/ob-ref hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-ref /home/dov/.config/emacs/org-mode/org-macs hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-macs /home/dov/.config/emacs/org-mode/ob-ledger hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-ledger /home/dov/.config/emacs/org-mode/org-clock hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-clock /home/dov/.config/emacs/org-mode/ob-calc hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-calc /home/dov/.config/emacs/org-mode/org-special-blocks hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-special-blocks /home/dov/.config/emacs/org-mode/org-mobile hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mobile /home/dov/.config/emacs/org-mode/ob-java hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-java /home/dov/.config/emacs/org-mode/org-table hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-table /home/dov/.config/emacs/org-mode/ob-awk hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-awk /home/dov/.config/emacs/org-mode/ob-lob hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-lob /home/dov/.config/emacs/org-mode/ob-haskell hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-haskell /home/dov/.config/emacs/org-mode/org-pcomplete hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-pcomplete /home/dov/.config/emacs/org-mode/ob-maxima hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-maxima /home/dov/.config/emacs/org-mode/ob-sql hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-sql /home/dov/.config/emacs/org-mode/ob-js hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-js /home/dov/.config/emacs/org-mode/org-irc hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-irc /home/dov/.config/emacs/org-mode/ob-R hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-R /home/dov/.config/emacs/org-mode/org-feed hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-feed /home/dov/.config/emacs/org-mode/org hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org /home/dov/.config/emacs/org-mode/ob-tangle hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/ob-tangle /home/dov/.config/emacs/org-mode/org-docview hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-docview /home/dov/.config/emacs/org-mode/org-gnus hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-gnus /home/dov/.config/emacs/org-mode/org-mac-message hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-mac-message /home/dov/.config/emacs/org-mode/org-bibtex hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-bibtex /home/dov/.config/emacs/org-mode/org-protocol hides /usr/local/public-dev/share/emacs/24.0.92/lisp/org/org-protocol /home/dov/.config/emacs/cedet/eieio/eieio-speedbar hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio-speedbar /home/dov/.config/emacs/cedet/eieio/eieio-custom hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio-custom /home/dov/.config/emacs/cedet/eieio/eieio-opt hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio-opt /home/dov/.config/emacs/cedet/eieio/chart hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/chart /home/dov/.config/emacs/cedet/eieio/eieio-base hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio-base /home/dov/.config/emacs/cedet/eieio/eieio hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio /home/dov/.config/emacs/cedet/eieio/eieio-datadebug hides /usr/local/public-dev/share/emacs/24.0.92/lisp/emacs-lisp/eieio-datadebug /home/dov/.config/emacs/cedet/common/cedet-files hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/cedet-files /home/dov/.config/emacs/cedet/common/inversion hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/inversion /home/dov/.config/emacs/cedet/common/data-debug hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/data-debug /home/dov/.config/emacs/cedet/ede/ede hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/ede /home/dov/.config/emacs/cedet/semantic/semantic hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/semantic /home/dov/.config/emacs/cedet/common/cedet-global hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/cedet-global /home/dov/.config/emacs/cedet/srecode/srecode hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/srecode /home/dov/.config/emacs/cedet/common/pulse hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/pulse /home/dov/.config/emacs/cedet/common/cedet-cscope hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/cedet-cscope /home/dov/.config/emacs/cedet/common/mode-local hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/mode-local /home/dov/.config/emacs/cedet/common/cedet-idutils hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/cedet-idutils /home/dov/.config/emacs/cedet/common/cedet hides /usr/local/public-dev/share/emacs/24.0.92/lisp/cedet/cedet Features: (shadow mail-extr emacsbug gdb-mi bindat json vc-git face-remap org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-info org-gnus org-docview org-bibtex bibtex org-bbdb paren zoom-frm qtdoc browse-url cedet ede-speedbar ede-files ede ede-base data-debug ede-auto eieio-speedbar speedbar ange-ftp sb-image ezimage dframe eieio-custom ede-source eieio-base mode-local find-func inversion git-find-file org-mw ob-plantuml ob-asymptote ob-dot ob-ditaa ob-python ob-perl ob-sh org-htmlslidy org-s5 persistent ipython executable org-export iimage org-install screenshot dmacro tramp tramp-compat tramp-loaddefs tex-mode shell color-moccur matlab-load sourcepair csv-mode sort dired-details+ dired-details mediawiki url-cache mm-url url-http tls url-auth url-gw python-mode ansi-color tempo url url-proxy url-privacy url-expand url-methods url-history url-cookie url-util url-parse auth-source eieio password-cache url-vars mailcap xml-parse doxymacs ack epresent org-latex org-export-latex org-beamer footnote org-exp ob-exp org-exp-blocks org-agenda org advice advice-preload ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob ob-eval org-pcomplete pcomplete org-list org-faces org-compat org-entities org-macs cal-menu calendar cal-loaddefs nnir gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems nnheader gnus-util xmsi-math-symbols-input mo-git-blame scroll-all markdown-mode noutline outline magit-bisect magit-key-mode assoc magit esh-var esh-io esh-cmd esh-ext esh-proc esh-arg eldoc esh-groups eshell esh-module esh-mode esh-util help-fns ido iswitchb diff-mode log-edit pcvs-util add-log vc-ediff octave-mod csharp-mode byte-opt bytecomp byte-compile cconv macroexp cc-langs doc-mode derived sgml-mode gud message format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader delsel warnings server javascript-mode newcomment icicles icicles-mode icicles-cmd frame-cmds frame-fns avoid dired+ dired-x dired-aux dired cus-edit cus-start cus-load yow cookie1 etags compile easy-mmode imenu comint ring bookmark pp dabbrev recentf tree-widget icicles-mcmd help-mode view icicles-mac icicles-fn cl icicles-face icicles-var icicles-opt ffap wid-edit edmacro kmacro thingatpt gtk-look info-look info vc ediff-merg ediff-diff ediff-wind ediff-help ediff-util ediff-mult ediff-init ediff vc-dispatcher cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 22 19:54:04 2012 Received: (at 10580) by debbugs.gnu.org; 23 Jan 2012 00:54:04 +0000 Received: from localhost ([127.0.0.1]:40346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rp8Ae-0004Se-Cy for submit@debbugs.gnu.org; Sun, 22 Jan 2012 19:54:04 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:35138 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rp8AZ-0004SE-50 for 10580@debbugs.gnu.org; Sun, 22 Jan 2012 19:54:02 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Rp8AM-00072y-SE; Sun, 22 Jan 2012 19:53:46 -0500 From: Glenn Morris To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: X-Spook: MD2 Freeh jihad ASPIC Saudi Arabia Firefly Cocaine X-Ran: wfV0tJTA#NKD{2/}WQmCTg.L@6Y&\:Wr|='MLd?j,JZ;f#mL;VJ{:Qq8=a2/R6',Mbgm@[ X-Hue: red X-Debbugs-No-Ack: yes X-Attribution: GM Date: Sun, 22 Jan 2012 19:53:46 -0500 In-Reply-To: (Dov Grobgeld's message of "Sun, 22 Jan 2012 14:42:01 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Dov Grobgeld wrote: > When trying to running gdb on my process, emacs gets stuck for more than > one minutes while the CPU load is at 100%. Does this happen with `emacs -Q'? Because it looks like you may not be using the gdb that comes with Emacs: > /home/dov/.config/emacs/gdb-mi hides > /usr/local/public-dev/share/emacs/24.0.92/lisp/progmodes/gdb-mi From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 23 04:21:29 2012 Received: (at 10580) by debbugs.gnu.org; 23 Jan 2012 09:21:29 +0000 Received: from localhost ([127.0.0.1]:40507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpG5g-0008B0-Kh for submit@debbugs.gnu.org; Mon, 23 Jan 2012 04:21:29 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:42265 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpG5d-0008As-LQ for 10580@debbugs.gnu.org; Mon, 23 Jan 2012 04:21:26 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RpG5O-0001I1-Px; Mon, 23 Jan 2012 04:21:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20253.9861.848886.122482@fencepost.gnu.org> Date: Mon, 23 Jan 2012 04:21:09 -0500 From: Glenn Morris To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-Reply-To: References: X-Attribution: GM X-Mailer: VM (www.wonderworks.com/vm), GNU Emacs (www.gnu.org/software/emacs) X-Hue: white X-Ran: 4@S6)\aVzJn_jJ%m@oJO{%M2j3hYi/M(+a}(=Xh4G-8djqo&pPwhe!-#Ydtt List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) (Please keep 10580@debbugs.gnu.org cc'd.) Dov Grobgeld wrote (on Mon, 23 Jan 2012 at 08:36 +0200): > Thanks for your reply Glenn. Is there a public bugzilla like site for > emacs bugs or are they managed in email only. I have additional > problems with gdb in emacs 24 and I would like to know if the problems > have been reported. You should have received this email acknowledgement of your report: http://debbugs.gnu.org/cgi/bugreport.cgi?msg=4;bug=10580 which contains a URL pointing to your report. From there you can easily find the front page: http://debbugs.gnu.org > I tried again with emacs -Q and the same thing happens. To be more > precise the startup time is about 40s at 100% CPU. Here is the output > from `report-emacs bug` when running with 'emacs -Q'. > > In GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.22.0) > of 2012-01-22 on dovg32 > Windowing system distributor `Fedora Project', version 11.0.10905000 > configured using `configure '--prefix=/usr/local/public-dev'' > > Important settings: > value of $LC_ALL: nil > value of $LC_COLLATE: nil > value of $LC_CTYPE: nil > value of $LC_MESSAGES: nil > value of $LC_MONETARY: nil > value of $LC_NUMERIC: nil > value of $LC_TIME: nil > value of $LANG: nil > value of $XMODIFIERS: @im=none > locale-coding-system: nil > default enable-multibyte-characters: t > > Major mode: Debugger > > Minor modes in effect: > tooltip-mode: t > mouse-wheel-mode: t > tool-bar-mode: t > menu-bar-mode: t > file-name-shadow-mode: t > global-font-lock-mode: t > font-lock-mode: t > blink-cursor-mode: t > auto-composition-mode: t > auto-encryption-mode: t > auto-compression-mode: t > line-number-mode: t > transient-mark-mode: t > > Recent input: > C-x C-f C-a C-y C-k C-a C-k > C-a C-k > > M-x g d b > > B i > n L 3 2 S o > > C-x k y e s M-x M-p > M-x g d b > b u g r e p > o r > > Recent messages: > For information about GNU Emacs and the GNU system, type C-h C-a. > current-kill: Kill ring is empty > Making completion list... > > Load-path shadows: > None found. > > Features: > (shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec > mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 > ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader > emacsbug help-mode easymenu view gdb-mi bindat json gud easy-mmode > comint ring dired regexp-opt time-date tooltip ediff-hook vc-hooks > lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe > lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar > mouse jit-lock font-lock syntax facemenu font-core frame cham georgian > utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean > japanese hebrew greek romanian slovak czech european ethiopic indian > cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev > minibuffer loaddefs button faces cus-face files text-properties overlay > sha1 md5 base64 format env code-pages mule custom widget > hashtable-print-readable backquote make-network-process dynamic-setting > system-font-setting font-render-setting move-toolbar gtk x-toolkit x > multi-tty emacs) From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 24 19:37:40 2012 Received: (at 10580) by debbugs.gnu.org; 25 Jan 2012 00:37:40 +0000 Received: from localhost ([127.0.0.1]:42386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rpqrs-0001Ku-8y for submit@debbugs.gnu.org; Tue, 24 Jan 2012 19:37:40 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:50525 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rpqrq-0001Km-2y for 10580@debbugs.gnu.org; Tue, 24 Jan 2012 19:37:38 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RpqrS-00058o-Gb; Tue, 24 Jan 2012 19:37:14 -0500 From: Glenn Morris To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> X-Spook: Downing Street constitution Al Jazeera fundamentalist X-Ran: I6bOSzd\q=S7`R@o+tnAYtrF^~]Oo!TyuM3)*+Pc5Aw2rx#(b^CbeJ?FpHXRkr@gNx/>J, X-Hue: white X-Attribution: GM Date: Tue, 24 Jan 2012 19:37:14 -0500 In-Reply-To: <20253.9861.848886.122482@fencepost.gnu.org> (Glenn Morris's message of "Mon, 23 Jan 2012 04:21:09 -0500") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) >> 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? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 25 03:50:02 2012 Received: (at 10580) by debbugs.gnu.org; 25 Jan 2012 08:50:02 +0000 Received: from localhost ([127.0.0.1]:42584 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpyYM-0004ra-Fr for submit@debbugs.gnu.org; Wed, 25 Jan 2012 03:50:02 -0500 Received: from mail-iy0-f172.google.com ([209.85.210.172]:49953) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RpyYK-0004qy-IK for 10580@debbugs.gnu.org; Wed, 25 Jan 2012 03:50:01 -0500 Received: by iagf6 with SMTP id f6so6350068iag.3 for <10580@debbugs.gnu.org>; Wed, 25 Jan 2012 00:49:29 -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=fnDYj+3nXMIkGI9ClFxt68Yr5v8o/B2a4dYHXl6G/Vs=; b=Fkxwuh48L+x03Jbdh08Hk6JdLFlvEubPvQJHia+tQ+C87X0GE/zY5TUzMqTLsKhVdg b1FBppzg2NXcTMbRjDpCRJyMxUjk8Ij/L8I1ywYwT1yYCesc+DkGktj8Njo75D4yOe1m xsjoi+bgpcEpKoHg9btTvjJwFmkAsT80FoG0E= MIME-Version: 1.0 Received: by 10.50.156.130 with SMTP id we2mr18040981igb.10.1327481369571; Wed, 25 Jan 2012 00:49:29 -0800 (PST) Received: by 10.42.158.196 with HTTP; Wed, 25 Jan 2012 00:49:29 -0800 (PST) In-Reply-To: References: <20253.9861.848886.122482@fencepost.gnu.org> Date: Wed, 25 Jan 2012 10:49:29 +0200 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Glenn Morris Content-Type: multipart/alternative; boundary=e89a8f2357ff7ab0ed04b75657e3 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8f2357ff7ab0ed04b75657e3 Content-Type: text/plain; charset=UTF-8 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? > --e89a8f2357ff7ab0ed04b75657e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are some mo= re tests:

1. It doesn't get stuck when debugging a "hello-w= orld.c" program. Thus it depends on the executable.
2. Regarding to= ggle-debug-on-quit and C-g, it doesn't work. No backtrace is produced a= nd 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?

--e89a8f2357ff7ab0ed04b75657e3-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 25 04:39:59 2012 Received: (at 10580) by debbugs.gnu.org; 25 Jan 2012 09:39:59 +0000 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 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 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= MIME-Version: 1.0 Received: by 10.50.156.130 with SMTP id we2mr18223573igb.10.1327484365163; Wed, 25 Jan 2012 01:39:25 -0800 (PST) Received: by 10.42.158.196 with HTTP; Wed, 25 Jan 2012 01:39:25 -0800 (PST) In-Reply-To: References: <20253.9861.848886.122482@fencepost.gnu.org> Date: Wed, 25 Jan 2012 11:39:25 +0200 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Glenn Morris Content-Type: multipart/alternative; boundary=e89a8f2357ff07cc9a04b7570af8 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --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-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 25 14:06:06 2012 Received: (at 10580) by debbugs.gnu.org; 25 Jan 2012 19:06:06 +0000 Received: from localhost ([127.0.0.1]:43786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rq8AY-0003pN-4C for submit@debbugs.gnu.org; Wed, 25 Jan 2012 14:06:06 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:47331 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rq8AV-0003pG-Ls for 10580@debbugs.gnu.org; Wed, 25 Jan 2012 14:06:04 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Rq8A3-0001th-DN; Wed, 25 Jan 2012 14:05:35 -0500 From: Glenn Morris To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> X-Spook: Tony Blair AVN bank credit card Albright BATF enforcers X-Ran: wZqxbqr&wBAbgx5>@yIsg3`SA&20q$+4;]$o8F (Dov Grobgeld's message of "Wed, 25 Jan 2012 11:39:25 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Dov Grobgeld wrote: > 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. Thanks for the detective work. I'm afraid I don't know what to do about this. It looks like process handling is messed up somehow. I hope someone else on this list can help you further. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 30 01:35:16 2012 Received: (at 10580) by debbugs.gnu.org; 30 Apr 2012 05:35:16 +0000 Received: from localhost ([127.0.0.1]:58367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SOjGW-0004pD-Iz for submit@debbugs.gnu.org; Mon, 30 Apr 2012 01:35:16 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:53256) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SOjGC-0004oT-Vo for 10580@debbugs.gnu.org; Mon, 30 Apr 2012 01:35:15 -0400 Received: by obbeh20 with SMTP id eh20so413218obb.3 for <10580@debbugs.gnu.org>; Sun, 29 Apr 2012 22:33:32 -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:content-transfer-encoding; bh=LrlpazO0eTAoq6t20btX6ozmumGLsl0BDy1U6O5bgtQ=; b=PHGGfQonZ0GMYmBQ3QL7T/CmR0QpDdev59kZ0RArZYCRFf0WXfEPLE/l4FlIOEQ8Wv Lswjp1vZi/H5eNaleEosU7AlMgOsW1aCFhcwHxihEbPesXRFCFr9HzUbflW6GpUVTeJj xX1i99OWv2bXSfLnZJOUK//37FR0T2mHKlCTrUwD0None+8pjNTqJVvP3RBXZpIgdDfK ZYm+7WoCPjfIIXD45rUSFC/VtQfWJ5PrLBGNwh+4w3EmOasRYbp8WYYaFVAhz7e1hNc+ DoNo8fony1tLXrOQxb14vVLamkcs9yAwV1g7xCIf1NqRnqEnmVcqA73+JTolk2k1o9tL biDg== MIME-Version: 1.0 Received: by 10.60.13.196 with SMTP id j4mr25904117oec.14.1335764012029; Sun, 29 Apr 2012 22:33:32 -0700 (PDT) Received: by 10.182.52.202 with HTTP; Sun, 29 Apr 2012 22:33:31 -0700 (PDT) In-Reply-To: References: <20253.9861.848886.122482@fencepost.gnu.org> Date: Mon, 30 Apr 2012 08:33:31 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Glenn Morris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) I finally ran emacs-24 under debugger to figure out where it got stuck. What I found was that it is stuck in keyboard.c where in read_key_sequence() the control keeps jumping back to the replay_sequence label. Does this ring a bell to someone? Regards, Dov On Wed, Jan 25, 2012 at 21:05, Glenn Morris wrote: > Dov Grobgeld wrote: > >> 2. The following command in gdb-input starts the 40s 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(concat command "= \n"))) >> >> where command=3D"1-inferior-tty-set /dev/pts/9". Note that the command >> returns immediately, but some other thread apparently gets very busy. > > Thanks for the detective work. I'm afraid I don't know what to do about > this. It looks like process handling is messed up somehow. > > I hope someone else on this list can help you further. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 30 02:38:08 2012 Received: (at 10580) by debbugs.gnu.org; 30 Apr 2012 06:38:09 +0000 Received: from localhost ([127.0.0.1]:58408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SOkFM-0006CM-Ct for submit@debbugs.gnu.org; Mon, 30 Apr 2012 02:38:08 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:46849) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SOkFJ-0006Bs-Oz for 10580@debbugs.gnu.org; Mon, 30 Apr 2012 02:38:06 -0400 Received: by obbeh20 with SMTP id eh20so454856obb.3 for <10580@debbugs.gnu.org>; Sun, 29 Apr 2012 23:36:40 -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:content-transfer-encoding; bh=IG+7Y9dMw7HR9V3Sjrn194PN/yUOUi6iaNg4EM9m8Ew=; b=nmzjQ5IirB+fzPxL9u9kcwwVIQnsgJIhfrO526g65ifRT5y61QBtZmg+VAzuBSoXUF 0b/2h2oXEDVczu6fyFkdfuNaVa61Hh0bk4PfG/vcwvkZ9C2AQQOoNMzoNehxNQYBBecL 1LMEBzhsswjCu5oCRJRj76bSyG+is7QsrjblgGKeYo7ulRYI+DU6U+JXkXmgV/f7QhFL IOrXZGAsNQSWGOvO7kN1LiZI0eWejBBbb+pmHjbggWKmtZ38HwP2DzJXTMjqCcmslQs6 qZ3mukZiRXOvBodPDXXO9kGatVmvuL4LkQTSviydkVov2M+LV0+bLq8LpOmHLel0ZQmT rqow== MIME-Version: 1.0 Received: by 10.182.155.35 with SMTP id vt3mr25795499obb.63.1335767800247; Sun, 29 Apr 2012 23:36:40 -0700 (PDT) Received: by 10.182.52.202 with HTTP; Sun, 29 Apr 2012 23:36:40 -0700 (PDT) In-Reply-To: References: <20253.9861.848886.122482@fencepost.gnu.org> Date: Mon, 30 Apr 2012 09:36:40 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Glenn Morris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Here is some more clarification. In keyboard.c:command_loop_1() the line i=3Dread_key_sequence() blocks during interactive work until a key is pressed. But when the process is stuck in "gdb" read_key_sequence() does not block but keeps returning. I still have no clue of what goes on though. On Mon, Apr 30, 2012 at 08:33, Dov Grobgeld wrote: > I finally ran emacs-24 under debugger to figure out where it got > stuck. What I found was that it is stuck in keyboard.c where in > read_key_sequence() the control keeps jumping back to the > replay_sequence label. Does this ring a bell to someone? > > Regards, > Dov > > > On Wed, Jan 25, 2012 at 21:05, Glenn Morris wrote: >> Dov Grobgeld wrote: >> >>> 2. The following command in gdb-input starts the 40s 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(concat command = "\n"))) >>> >>> where command=3D"1-inferior-tty-set /dev/pts/9". Note that the command >>> returns immediately, but some other thread apparently gets very busy. >> >> Thanks for the detective work. I'm afraid I don't know what to do about >> this. It looks like process handling is messed up somehow. >> >> I hope someone else on this list can help you further. From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 00:15:52 2012 Received: (at 10580) by debbugs.gnu.org; 6 May 2012 04:15:52 +0000 Received: from localhost ([127.0.0.1]:37591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQssy-0007Hl-9O for submit@debbugs.gnu.org; Sun, 06 May 2012 00:15:52 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:54291 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQssv-0007Hd-OJ for 10580@debbugs.gnu.org; Sun, 06 May 2012 00:15:50 -0400 Received: from bb116-15-158-8.singnet.com.sg ([116.15.158.8]:51528 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SQsr4-0002z1-6v; Sun, 06 May 2012 00:13:54 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> Date: Sun, 06 May 2012 12:13:46 +0800 In-Reply-To: (Dov Grobgeld's message of "Mon, 30 Apr 2012 09:36:40 +0300") Message-ID: <87aa1mj69x.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > Here is some more clarification. In keyboard.c:command_loop_1() the > line i=read_key_sequence() blocks during interactive work until a key > is pressed. But when the process is stuck in "gdb" read_key_sequence() > does not block but keeps returning. I still have no clue of what goes > on though. Is this still with 24.0.92, or the latest pretest 24.0.96, or the emacs-24 branch? I made some changes to the pty handling a few weeks ago (which should be included in 24.0.96), which may impact this issue. From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 00:57:31 2012 Received: (at 10580) by debbugs.gnu.org; 6 May 2012 04:57:31 +0000 Received: from localhost ([127.0.0.1]:37637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQtXG-0001SX-ID for submit@debbugs.gnu.org; Sun, 06 May 2012 00:57:31 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:58007) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQtXE-0001SK-DF for 10580@debbugs.gnu.org; Sun, 06 May 2012 00:57:29 -0400 Received: by obbeh20 with SMTP id eh20so6248549obb.3 for <10580@debbugs.gnu.org>; Sat, 05 May 2012 21:55:29 -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=hYCRU5Mq3UyWB7P+OblZUufzjSskaBvKNqQUKoLkcwk=; b=acQuF7QXtp+Z79PUCwFvjHk0Jr4gGEjjiq1ihdUZbv2EnLO5bPyKAJUmuHYHEy/4WI /Q3hwxKOfBt5fLaGjVrIo6IQ+PaVGFTZ92CxgfdSpGTG29qQ7xw6f9NPYn+UheEjIbXi vD33jqjoqBIBU83P2necX78mgbByRb1jIynVL5myhOkmkmws9GkOn2dFGLe/e9ceHqO+ YAKQESmfiFkPUWVFlTwo4+kE04myClg5l9bn4Iyl7W6EFciNMRtayeltLLhebLZXwtnM O72y4jRw47VJAqeJjSVDlFeCB7SoLk4TAfzSAyXUlFGwG/Y4cl6tfkAxZDcJ3i/2d9BO 5WqQ== MIME-Version: 1.0 Received: by 10.60.21.103 with SMTP id u7mr15777463oee.11.1336280129345; Sat, 05 May 2012 21:55:29 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Sat, 5 May 2012 21:55:29 -0700 (PDT) In-Reply-To: <87aa1mj69x.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> Date: Sun, 6 May 2012 07:55:29 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8ff1c71e6e19a804bf56f68e X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8ff1c71e6e19a804bf56f68e Content-Type: text/plain; charset=UTF-8 Thank you very much for looking into this. For me, this is currently, the main show stopper for starting to emacs-24. I have just tested the same scenario with the latest git HEAD version from http://git.savannah.gnu.org/r/emacs.git/ : 823d681 Optionally include holidays in cal-html output and unfortunately the exact same behavior as before still remains. Please let me know if there are any tests or debug info that I can provide you with that can help in resolving this issue. I tried debugging it myself, but I found it to complex since I lack the knowledge of how sub-processes are handled in emacs. Regards, Dov On Sun, May 6, 2012 at 7:13 AM, Chong Yidong wrote: > Dov Grobgeld writes: > > > Here is some more clarification. In keyboard.c:command_loop_1() the > > line i=read_key_sequence() blocks during interactive work until a key > > is pressed. But when the process is stuck in "gdb" read_key_sequence() > > does not block but keeps returning. I still have no clue of what goes > > on though. > > Is this still with 24.0.92, or the latest pretest 24.0.96, or the > emacs-24 branch? I made some changes to the pty handling a few weeks > ago (which should be included in 24.0.96), which may impact this issue. > --e89a8ff1c71e6e19a804bf56f68e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very m= uch for looking into this. For me, this is currently, the main show stopper= for starting to emacs-24.

I have just tested the same scenario with= the latest git HEAD version from http://git.savannah.gnu.org/r/emacs.git/ :

823d681 Optionally include holidays in cal-html output

and unfor= tunately the exact same behavior as before still remains.

Please let= me know if there are any tests or debug info that I can provide you with t= hat can help in resolving this issue. I tried debugging it myself, but I fo= und it to complex since I lack the knowledge of how sub-processes are handl= ed in emacs.

Regards,
Dov

On Sun, May 6,= 2012 at 7:13 AM, Chong Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> Here is some more clarification. In keyboard.c:command_loop_1() the > line i=3Dread_key_sequence() blocks during interactive work until a ke= y
> is pressed. But when the process is stuck in "gdb" read_key_= sequence()
> does not block but keeps returning. I still have no clue of what goes<= br> > on though.

Is this still with 24.0.92, or the latest pretest 24.0.96, or the
emacs-24 branch? =C2=A0I made some changes to the pty handling a few weeks<= br> ago (which should be included in 24.0.96), which may impact this issue.

--e89a8ff1c71e6e19a804bf56f68e-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 01:42:03 2012 Received: (at 10580) by debbugs.gnu.org; 6 May 2012 05:42:03 +0000 Received: from localhost ([127.0.0.1]:37657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuEN-0004AU-GK for submit@debbugs.gnu.org; Sun, 06 May 2012 01:42:03 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:54967 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQuEK-0004A5-Uk for 10580@debbugs.gnu.org; Sun, 06 May 2012 01:42:01 -0400 Received: from bb116-15-158-8.singnet.com.sg ([116.15.158.8]:51734 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SQuCS-0006zv-I6; Sun, 06 May 2012 01:40:05 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> Date: Sun, 06 May 2012 13:39:56 +0800 In-Reply-To: (Dov Grobgeld's message of "Sun, 6 May 2012 07:55:29 +0300") Message-ID: <87havtvpeb.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > Please let me know if there are any tests or debug info that I can > provide you with that can help in resolving this issue. I tried > debugging it myself, but I found it to complex since I lack the > knowledge of how sub-processes are handled in emacs. If you look at the *input/output of a.out* buffer, does it contain any text? Also, when you say that read_key_sequence keeps returning, what is its return value? Also, when read_key_sequence returns early, what is the value returned by read_char at keyboard.c:9341? Also, is it possible for you to provide a copy of the problematic program, or is it not allowed? From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 03:08:18 2012 Received: (at 10580) by debbugs.gnu.org; 6 May 2012 07:08:18 +0000 Received: from localhost ([127.0.0.1]:37711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQvZo-0006CN-Og for submit@debbugs.gnu.org; Sun, 06 May 2012 03:08:17 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:41146) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SQvZl-0006C9-2g for 10580@debbugs.gnu.org; Sun, 06 May 2012 03:08:15 -0400 Received: by obbeh20 with SMTP id eh20so6356600obb.3 for <10580@debbugs.gnu.org>; Sun, 06 May 2012 00:06:13 -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=IW7O5ud0FPWMLkOXaD8bhR4S8fm8HqcN2Z5mneqFEtE=; b=bcGMG2DxGNcfKILv1J3vNEzid0ytvKz5tJRHMVWD0GOjiz1WdX1XCUpbBlvNWCBeVU reCP+FU1lqOUwkLTALytDtwcUSkApd4SJYxFK7EMXV6ZaJ+MRKC1twOGWY/RcMqtyHoU Lcb5tQgie4jiNYGNzmF42oSvRi5+Jk7vHzl55hynXoFM5K9nRbQAKje/C1kyyR7Pbp0J gAKoFrGv/cVu4GngfxybZZKJfZD9nsxt/Ivh1mMuTn8VgqigBtqoShQ+Oi/wfT7Y170K mnxvr3Qm5kEIMYnwWRkKM2sTx8E6iQYaHMIWCH7zEoBQ5+1gDCCo7yQOgLsM5oHOZvab ZQKA== MIME-Version: 1.0 Received: by 10.60.13.36 with SMTP id e4mr15896509oec.22.1336287973703; Sun, 06 May 2012 00:06:13 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Sun, 6 May 2012 00:06:13 -0700 (PDT) In-Reply-To: <87havtvpeb.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> Date: Sun, 6 May 2012 10:06:13 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8ff1c1b0fd80c904bf58c9a2 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8ff1c1b0fd80c904bf58c9a2 Content-Type: text/plain; charset=UTF-8 The *input/output of a.out* is empty. It seems that I was wrong about read_key_sequence(). It doesn't "return early". Here is a stack trace during the timeout: #0 0x00110424 in __kernel_vsyscall () #1 0x005f288d in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:82 #2 0x08149691 in xg_select (max_fds=17, rfds=0xbfffe860, wfds=0xbfffe7e0, efds=0x0, timeout=0xbfffe7d4) at xgselect.c:100 #3 0x0821ffb0 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=138903722, wait_proc=0x0, just_wait_proc=0) at process.c:4620 #4 0x080601c7 in sit_for (timeout=120, reading=1, do_display=1) at dispnew.c:6068 #5 0x08159606 in read_char (commandflag=1, nmaps=3, maps=0xbfffec50, prev_event=138903722, used_mouse_menu=0xbfffed18, end_time=0x0) at keyboard.c:2698 #6 0x08163f12 in read_key_sequence (keybuf=0xbfffee94, bufsize=30, prompt=138903722, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9341 #7 0x08157472 in command_loop_1 () at keyboard.c:1455 #8 0x081d629d in internal_condition_case (bfun=0x815711b , handlers=138934706, hfun=0x8156ad5 ) at eval.c:1448 #9 0x08156e49 in command_loop_2 (ignore=138903722) at keyboard.c:1160 #10 0x081d5d6f in internal_catch (tag=138932706, func=0x8156e25 , arg=138903722) at eval.c:1205 #11 0x08156e05 in command_loop () at keyboard.c:1139 #12 0x0815670e in recursive_edit_1 () at keyboard.c:759 #13 0x0815685f in Frecursive_edit () at keyboard.c:823 #14 0x08154d65 in main (argc=1, argv=0xbffff5e4) at emacs.c:1711 read_char() returns 158534621. Sorry, I can't redistribute the executable. If the problem can't be solved by otherwise, I'll try to generate another executable that has this problem. In any case, here is the output when running gdb from the command line on the executable. > gdb -i=mi SolarJet =thread-group-added,id="i1" ~"GNU gdb (GDB) Fedora (7.2-52.fc14)\n" ~"Copyright (C) 2010 Free Software Foundation, Inc.\n" ~"License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n" ~"This GDB was configured as \"i686-redhat-linux-gnu\".\nFor bug reporting instructions, please see:\n" ~"...\n" ~"Reading symbols from /mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/qt/BinLinux32/SolarJet..." ~"done.\n" (gdb) Thanks, Dov On Sun, May 6, 2012 at 8:39 AM, Chong Yidong wrote: > Dov Grobgeld writes: > > > Please let me know if there are any tests or debug info that I can > > provide you with that can help in resolving this issue. I tried > > debugging it myself, but I found it to complex since I lack the > > knowledge of how sub-processes are handled in emacs. > > If you look at the *input/output of a.out* buffer, does it contain any > text? > > Also, when you say that read_key_sequence keeps returning, what is its > return value? Also, when read_key_sequence returns early, what is the > value returned by read_char at keyboard.c:9341? > > Also, is it possible for you to provide a copy of the problematic > program, or is it not allowed? > --e89a8ff1c1b0fd80c904bf58c9a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The *input/outpu= t of a.out* is empty.

It seems that I was wrong about read_key_seque= nce(). It doesn't "return early". Here is a stack trace durin= g the timeout:

#0=C2=A0 0x00110424 in __kernel_vsyscall ()
#1=C2=A0 0x005f288d in _= __newselect_nocancel () at ../sysdeps/unix/syscall-template.S:82
#2=C2= =A0 0x08149691 in xg_select (max_fds=3D17, rfds=3D0xbfffe860, wfds=3D0xbfff= e7e0, efds=3D0x0, timeout=3D0xbfffe7d4) at xgselect.c:100
#3=C2=A0 0x0821ffb0 in wait_reading_process_output (time_limit=3D30, micros= ecs=3D0, read_kbd=3D-1, do_display=3D1, wait_for_cell=3D138903722, wait_pro= c=3D0x0, just_wait_proc=3D0) at process.c:4620
#4=C2=A0 0x080601c7 in si= t_for (timeout=3D120, reading=3D1, do_display=3D1) at dispnew.c:6068
#5=C2=A0 0x08159606 in read_char (commandflag=3D1, nmaps=3D3, maps=3D0xbfff= ec50, prev_event=3D138903722, used_mouse_menu=3D0xbfffed18, end_time=3D0x0)= at keyboard.c:2698
#6=C2=A0 0x08163f12 in read_key_sequence (keybuf=3D0= xbfffee94, bufsize=3D30, prompt=3D138903722, dont_downcase_last=3D0, can_re= turn_switch_frame=3D1, fix_current_buffer=3D1) at keyboard.c:9341
#7=C2=A0 0x08157472 in command_loop_1 () at keyboard.c:1455
#8=C2=A0 0x0= 81d629d in internal_condition_case (bfun=3D0x815711b <command_loop_1>= , handlers=3D138934706, hfun=3D0x8156ad5 <cmd_error>) at eval.c:1448<= br>#9=C2=A0 0x08156e49 in command_loop_2 (ignore=3D138903722) at keyboard.c= :1160
#10 0x081d5d6f in internal_catch (tag=3D138932706, func=3D0x8156e25 <com= mand_loop_2>, arg=3D138903722) at eval.c:1205
#11 0x08156e05 in comma= nd_loop () at keyboard.c:1139
#12 0x0815670e in recursive_edit_1 () at k= eyboard.c:759
#13 0x0815685f in Frecursive_edit () at keyboard.c:823
#14 0x08154d65 in= main (argc=3D1, argv=3D0xbffff5e4) at emacs.c:1711

read_char() retu= rns 158534621.

Sorry, I can't redistribute the executable= . If the problem can't be solved by otherwise, I'll try to generate= another executable that has this problem. In any case, here is the output = when running gdb from the command line on the executable.

> gdb -i=3Dmi SolarJet
=3Dthread-group-added,id=3D"i1"<= br>~"GNU gdb (GDB) Fedora (7.2-52.fc14)\n"
~"Copyright (C= ) 2010 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU= GPL version 3 or later <ht= tp://gnu.org/licenses/gpl.html>\nThis is free software: you are free= to change and redistribute it.\nThere is NO WARRANTY, to the extent permit= ted by law.=C2=A0 Type \"show copying\"\nand \"show warranty= \" for details.\n"
~"This GDB was configured as \"i686-redhat-linux-gnu\".\nFor= bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/= >...\n"
~"Reading symbols from /mnt/fdrive/git/SolarJet/Apps/SolarJet/Project/= qt/BinLinux32/SolarJet..."
~"done.\n"
(gdb)

Th= anks,
Dov

On Sun, May 6, 2012 at 8:39 = AM, Chong Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:
> Please let me know if there are any tests or debug info that I can
> provide you with that can help in resolving this issue. I tried
> debugging it myself, but I found it to complex since I lack the
> knowledge of how sub-processes are handled in emacs.

If you look at the *input/output of a.out* buffer, does it contain an= y
text?

Also, when you say that read_key_sequence keeps returning, what is its
return value? =C2=A0Also, when read_key_sequence returns early, what is the=
value returned by read_char at keyboard.c:9341?

Also, is it possible for you to provide a copy of the problematic
program, or is it not allowed?

--e89a8ff1c1b0fd80c904bf58c9a2-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 06 22:56:04 2012 Received: (at 10580) by debbugs.gnu.org; 7 May 2012 02:56:04 +0000 Received: from localhost ([127.0.0.1]:39006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRE7I-00032N-8d for submit@debbugs.gnu.org; Sun, 06 May 2012 22:56:04 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:40883 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRE7F-00031y-Od for 10580@debbugs.gnu.org; Sun, 06 May 2012 22:56:02 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:49691 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SRE5J-0001P7-1n; Sun, 06 May 2012 22:54:02 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> Date: Mon, 07 May 2012 10:53:52 +0800 In-Reply-To: (Dov Grobgeld's message of "Sun, 6 May 2012 10:06:13 +0300") Message-ID: <874nrsem67.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) 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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 07 01:09:56 2012 Received: (at 10580) by debbugs.gnu.org; 7 May 2012 05:09:56 +0000 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 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 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== MIME-Version: 1.0 Received: by 10.60.4.199 with SMTP id m7mr19526394oem.65.1336367264986; Sun, 06 May 2012 22:07:44 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Sun, 6 May 2012 22:07:44 -0700 (PDT) In-Reply-To: <874nrsem67.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> Date: Mon, 7 May 2012 08:07:44 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8ff1c1661e77d504bf6b40a3 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --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-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 07 02:13:56 2012 Received: (at 10580) by debbugs.gnu.org; 7 May 2012 06:13:56 +0000 Received: from localhost ([127.0.0.1]:39041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHCk-0007TW-F7 for submit@debbugs.gnu.org; Mon, 07 May 2012 02:13:56 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:44592 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHCi-0007TP-08 for 10580@debbugs.gnu.org; Mon, 07 May 2012 02:13:53 -0400 Received: from [155.69.19.224] (port=52351 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SRHAk-00011G-DB; Mon, 07 May 2012 02:11:51 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> Date: Mon, 07 May 2012 14:11:42 +0800 In-Reply-To: (Dov Grobgeld's message of "Mon, 7 May 2012 08:07:44 +0300") Message-ID: <874nrswme9.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: Glenn Morris , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > 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. Please apply the following patch, then, when Emacs is taking 100% CPU, set a breakpoint at process.c:4854, i.e. at if (p->pid == -2) ; This captures the state just after Emacs calls read_process_output on the pty passed to your program. If this breakpoint is triggered, please report the value of nread and errno, and step through to the end of the subsequent if/else block and report the gdb session. Thanks. === modified file 'src/process.c' *** src/process.c 2012-04-20 06:39:29 +0000 --- src/process.c 2012-05-07 06:09:25 +0000 *************** *** 4847,4852 **** --- 4847,4859 ---- buffered-ahead character if we have one. */ nread = read_process_output (proc, channel); + + { + struct Lisp_Process *p = XPROCESS (proc); + if (p->pid == -2) + ; + } + if (nread > 0) { /* Since read_process_output can run a filter, From debbugs-submit-bounces@debbugs.gnu.org Mon May 07 02:28:27 2012 Received: (at 10580) by debbugs.gnu.org; 7 May 2012 06:28:27 +0000 Received: from localhost ([127.0.0.1]:39051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHQo-0007no-T5 for submit@debbugs.gnu.org; Mon, 07 May 2012 02:28:27 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:44716 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRHQm-0007ng-4Y for 10580@debbugs.gnu.org; Mon, 07 May 2012 02:28:25 -0400 Received: from [155.69.19.224] (port=52420 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SRHOo-00048Y-NC; Mon, 07 May 2012 02:26:23 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> Date: Mon, 07 May 2012 14:26:14 +0800 In-Reply-To: <874nrswme9.fsf@gnu.org> (Chong Yidong's message of "Mon, 07 May 2012 14:11:42 +0800") Message-ID: <87zk9kv75l.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Actually, try the following patch instead (apparently gdb has some issues with printing errno). Apply the patch, then when Emacs is taking 100% CPU do an interrupt and set the breakpoint at process.c:4855, then when the breakpoint triggers do n p nread p errno and step through the subsequent if/else blocks. Thanks. Basically, the 100% CPU appears to be because Emacs' select() call keeps getting worken up by the pty attached to your program. But, for some reason, no actual output being read from that pty. These debugging steps are trying to figure out if some uncaught errno is being reported by the pty read. === modified file 'src/process.c' *** src/process.c 2012-04-20 06:39:29 +0000 --- src/process.c 2012-05-07 06:21:39 +0000 *************** *** 4822,4827 **** --- 4822,4829 ---- && !FD_ISSET (channel, &non_process_wait_mask)) { int nread; + int saved_errno = 0; + struct Lisp_Process *pp; /* If waiting for this channel, arrange to return as soon as no more input to be processed. No more *************** *** 4847,4852 **** --- 4849,4859 ---- buffered-ahead character if we have one. */ nread = read_process_output (proc, channel); + + pp = XPROCESS (proc); + if (pp->pid == -2) + saved_errno = errno; + if (nread > 0) { /* Since read_process_output can run a filter, From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 01:35:28 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 05:35:28 +0000 Received: from localhost ([127.0.0.1]:40305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRd56-0001V2-Bf for submit@debbugs.gnu.org; Tue, 08 May 2012 01:35:28 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:52362) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRd54-0001Uq-6i for 10580@debbugs.gnu.org; Tue, 08 May 2012 01:35:27 -0400 Received: by obbeh20 with SMTP id eh20so9205304obb.3 for <10580@debbugs.gnu.org>; Mon, 07 May 2012 22:33:16 -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=vAehw2ExiLV3xwgN1Bt5oTfJpR7VB4F/PgwFir+cM/I=; b=ygyDCX9CHJ4WB7BLVzSRtbRAgr9UFNaX0CHrlvkgjex6FmJ7+GSeI8fffGlTnfdGXt TbAImb392vT+nTSzu/o7l2YQwcmkhztOl/pPWKLgFMT40x5roBdcJOvE9i/MC4SY4wAD AyA0wv/FYLH++U55HJ5xaqM8rt5X1aj8UJR7EqjHuYgzTI03w15vD+J0BAF+PaYnPJFw hLydIHZ+SLGf1x3KwSmwYQuPLfFcpK9eygHwPmpMU21kH4aPu+/GvoGPmqIAQ8m/7WQe 5BRllRZxmDvcgJx4ETGN9kLOcUE1adwUsj+LtfSW6PRhd/DZDcIATVXwwOAV6x5HCNfR BlaQ== MIME-Version: 1.0 Received: by 10.60.29.39 with SMTP id g7mr2137377oeh.6.1336455195931; Mon, 07 May 2012 22:33:15 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Mon, 7 May 2012 22:33:15 -0700 (PDT) In-Reply-To: <87zk9kv75l.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> Date: Tue, 8 May 2012 08:33:15 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8ff2563236337204bf7fb933 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8ff2563236337204bf7fb933 Content-Type: text/plain; charset=UTF-8 I added the above patch and the result is as follows: After the following two lines: nread = read_process_output (proc, channel); pp = XPROCESS(proc); nread==4095, pp->pid=1234 repeatedly. (Actually 1234 seems to be an arbitrary, but constant number between 1000 and 2000). This seems strange, as obviously the sub-process does not produce 4095 characters repeatedly. Thanks, Dov On Mon, May 7, 2012 at 9:26 AM, Chong Yidong wrote: > Actually, try the following patch instead (apparently gdb has some > issues with printing errno). Apply the patch, then when Emacs is taking > 100% CPU do an interrupt and set the breakpoint at process.c:4855, then > when the breakpoint triggers do > > n > p nread > p errno > > and step through the subsequent if/else blocks. Thanks. > > Basically, the 100% CPU appears to be because Emacs' select() call keeps > getting worken up by the pty attached to your program. But, for some > reason, no actual output being read from that pty. These debugging > steps are trying to figure out if some uncaught errno is being reported > by the pty read. > > > === modified file 'src/process.c' > *** src/process.c 2012-04-20 06:39:29 +0000 > --- src/process.c 2012-05-07 06:21:39 +0000 > *************** > *** 4822,4827 **** > --- 4822,4829 ---- > && !FD_ISSET (channel, &non_process_wait_mask)) > { > int nread; > + int saved_errno = 0; > + struct Lisp_Process *pp; > > /* If waiting for this channel, arrange to return as > soon as no more input to be processed. No more > *************** > *** 4847,4852 **** > --- 4849,4859 ---- > buffered-ahead character if we have one. */ > > nread = read_process_output (proc, channel); > + > + pp = XPROCESS (proc); > + if (pp->pid == -2) > + saved_errno = errno; > + > if (nread > 0) > { > /* Since read_process_output can run a filter, > > --e89a8ff2563236337204bf7fb933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I added the abov= e patch and the result is as follows:

After the following two lines:=

=C2=A0=C2=A0=C2=A0 nread =3D read_process_output (proc, channel);
=C2=A0=C2=A0=C2=A0 pp =3D XPROCESS(proc);

nread=3D=3D4095, pp->pid=3D1234 repeatedly. (Actually 1234 seems to = be an arbitrary, but constant number between 1000 and 2000).

This s= eems strange, as obviously the sub-process does not produce 4095 characters= repeatedly.

Thanks,
Dov

On Mon, May 7, = 2012 at 9:26 AM, Chong Yidong <cyd@gnu.org> wrote:
Actually, try the following patch instead (apparently gdb has some
issues with printing errno). =C2=A0Apply the patch, then when Emacs is taki= ng
100% CPU do an interrupt and set the breakpoint at process.c:4855, then
when the breakpoint triggers do

n
p nread
p errno

and step through the subsequent if/else blocks. =C2=A0Thanks.

Basically, the 100% CPU appears to be because Emacs' select() call keep= s
getting worken up by the pty attached to your program. =C2=A0But, for some<= br> reason, no actual output being read from that pty. =C2=A0These debugging steps are trying to figure out if some uncaught errno is being reported
by the pty read.


=3D=3D=3D modified file 'src/process.c'
*** src/process.c =C2=A0 =C2=A0 =C2=A0 2012-04-20 06:39:29 +0000
--- src/process.c =C2=A0 =C2=A0 =C2=A0 2012-05-07 06:21:39 +0000
***************
*** 4822,4827 ****
--- 4822,4829 ----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&& !FD_ISSE= T (channel, &non_process_wait_mask))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int nread;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int saved_errno =3D 0;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Lisp_Process *pp;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If waiting for this cha= nnel, arrange to return as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 soon as no more in= put to be processed. =C2=A0No more
***************
*** 4847,4852 ****
--- 4849,4859 ----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = buffered-ahead character if we have one. =C2=A0*/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nread =3D read_process_out= put (proc, channel);
+
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pp =3D = XPROCESS (proc);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (pp->pid =3D=3D -2)=
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 saved_errno =3D errno;
+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (nread > 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Since rea= d_process_output can run a filter,


--e89a8ff2563236337204bf7fb933-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 03:58:38 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 07:58:38 +0000 Received: from localhost ([127.0.0.1]:40387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfJc-0004hC-GV for submit@debbugs.gnu.org; Tue, 08 May 2012 03:58:37 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:49589) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfJZ-0004gy-2J for 10580@debbugs.gnu.org; Tue, 08 May 2012 03:58:34 -0400 Received: by obbeh20 with SMTP id eh20so9352449obb.3 for <10580@debbugs.gnu.org>; Tue, 08 May 2012 00:56:22 -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=q1TKw5VTdr+07Ai9jsb2/BbKHUN+2i/3MUsewmRmOUk=; b=PpNgBdwcLeZCfdNIrHw0OnHTfHwuJRjBLyfHvYSblaLOIh86ToqySoU8Jk8Ttx0vg/ sUymzvXn4T6wIiZXO1irvTnxOxBkDJ0C2/5i2drkmliWU/yuL0AD+x/tZdPmzCb4AzvE UmyYrEttgpsXmmiqM29i5MEiGcbBgnqQnNFzEhGGYTyp1JK33drWGiivRER01QN6Rp26 /Lgn2kviYeZgfFX8LwmFVmLsrZALy9zu4VSqNu9zldElS8kBngK53a0DvXfrH9X5AZoZ XAbrcPMl8UbUnATn/ZKMGZQrDLY+7/un6H6WJrQ94izgCd0s38aypZzs+8cipAxahwYX z0cQ== MIME-Version: 1.0 Received: by 10.182.159.5 with SMTP id wy5mr1513462obb.24.1336463782106; Tue, 08 May 2012 00:56:22 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Tue, 8 May 2012 00:56:21 -0700 (PDT) In-Reply-To: References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> Date: Tue, 8 May 2012 10:56:21 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=14dae9399bd9fcd52004bf81b86d X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --14dae9399bd9fcd52004bf81b86d Content-Type: text/plain; charset=UTF-8 Some more info that I found through strace that might help. Alltogether read_process_output() is called 214 times and thus a total of 870k of text is read through /dev/ptmx to read_process_output() . Could the amount of data possibly explain the slowness? Regards, Dov On Tue, May 8, 2012 at 8:33 AM, Dov Grobgeld wrote: > I added the above patch and the result is as follows: > > After the following two lines: > > > nread = read_process_output (proc, channel); > > pp = XPROCESS(proc); > > nread==4095, pp->pid=1234 repeatedly. (Actually 1234 seems to be an > arbitrary, but constant number between 1000 and 2000). > > This seems strange, as obviously the sub-process does not produce 4095 > characters repeatedly. > > Thanks, > Dov > > On Mon, May 7, 2012 at 9:26 AM, Chong Yidong wrote: > >> Actually, try the following patch instead (apparently gdb has some >> issues with printing errno). Apply the patch, then when Emacs is taking >> 100% CPU do an interrupt and set the breakpoint at process.c:4855, then >> when the breakpoint triggers do >> >> n >> p nread >> p errno >> >> and step through the subsequent if/else blocks. Thanks. >> >> Basically, the 100% CPU appears to be because Emacs' select() call keeps >> getting worken up by the pty attached to your program. But, for some >> reason, no actual output being read from that pty. These debugging >> steps are trying to figure out if some uncaught errno is being reported >> by the pty read. >> >> >> === modified file 'src/process.c' >> *** src/process.c 2012-04-20 06:39:29 +0000 >> --- src/process.c 2012-05-07 06:21:39 +0000 >> *************** >> *** 4822,4827 **** >> --- 4822,4829 ---- >> && !FD_ISSET (channel, &non_process_wait_mask)) >> { >> int nread; >> + int saved_errno = 0; >> + struct Lisp_Process *pp; >> >> /* If waiting for this channel, arrange to return as >> soon as no more input to be processed. No more >> *************** >> *** 4847,4852 **** >> --- 4849,4859 ---- >> buffered-ahead character if we have one. */ >> >> nread = read_process_output (proc, channel); >> + >> + pp = XPROCESS (proc); >> + if (pp->pid == -2) >> + saved_errno = errno; >> + >> if (nread > 0) >> { >> /* Since read_process_output can run a filter, >> >> > --14dae9399bd9fcd52004bf81b86d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some more info t= hat I found through strace that might help. Alltogether read_process_output= () is called 214 times and thus a total of 870k of text is read through /de= v/ptmx to read_process_output() . Could the amount of data possibly explain= the slowness?

Regards,
Dov

On Tue, May 8,= 2012 at 8:33 AM, Dov Grobgeld <dov.grobgeld@gmail.com>= wrote:
I added the above patch and the result is as follows:
After the following two lines:


=C2=A0=C2=A0=C2=A0 nread =3D read_process_output (proc, channel);
=C2=A0=C2=A0=C2=A0 pp =3D XPROCESS(proc);

nread=3D=3D4095, pp->pid=3D1234 repeatedly. (Actually 1234 seems to = be an arbitrary, but constant number between 1000 and 2000).

This s= eems strange, as obviously the sub-process does not produce 4095 characters= repeatedly.

Thanks,
Dov

On Mon, May 7, 2012 at 9:26 AM, Chong Yidong <= cyd@gnu.org>= wrote:
Actually, try the following patch instead (apparently gdb has some
issues with printing errno). =C2=A0Apply the patch, then when Emacs is taki= ng
100% CPU do an interrupt and set the breakpoint at process.c:4855, then
when the breakpoint triggers do

n
p nread
p errno

and step through the subsequent if/else blocks. =C2=A0Thanks.

Basically, the 100% CPU appears to be because Emacs' select() call keep= s
getting worken up by the pty attached to your program. =C2=A0But, for some<= br> reason, no actual output being read from that pty. =C2=A0These debugging steps are trying to figure out if some uncaught errno is being reported
by the pty read.


=3D=3D=3D modified file 'src/process.c'
*** src/process.c =C2=A0 =C2=A0 =C2=A0 2012-04-20 06:39:29 +0000
--- src/process.c =C2=A0 =C2=A0 =C2=A0 2012-05-07 06:21:39 +0000
***************
*** 4822,4827 ****
--- 4822,4829 ----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&& !FD_ISSE= T (channel, &non_process_wait_mask))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int nread;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int saved_errno =3D 0;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct Lisp_Process *pp;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* If waiting for this cha= nnel, arrange to return as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 soon as no more in= put to be processed. =C2=A0No more
***************
*** 4847,4852 ****
--- 4849,4859 ----
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 buffered-ahea= d character if we have one. =C2=A0*/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nread =3D read_process_out= put (proc, channel);
+
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pp =3D XPROCESS (pro= c);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (pp->pid =3D=3D -2)=
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 saved_errno =3D errno;
+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (nread > 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Since rea= d_process_output can run a filter,



--14dae9399bd9fcd52004bf81b86d-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 04:30:45 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 08:30:45 +0000 Received: from localhost ([127.0.0.1]:40397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfoi-0005Pu-M6 for submit@debbugs.gnu.org; Tue, 08 May 2012 04:30:45 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:43053 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRfog-0005Pn-Uo for 10580@debbugs.gnu.org; Tue, 08 May 2012 04:30:43 -0400 Received: from [155.69.17.96] (port=54955 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SRfmc-00011d-HC; Tue, 08 May 2012 04:28:35 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> Date: Tue, 08 May 2012 16:28:27 +0800 In-Reply-To: (Dov Grobgeld's message of "Tue, 8 May 2012 10:56:21 +0300") Message-ID: <87mx5j6pqs.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > I added the above patch and the result is as follows: > After the following two lines: > > =C2=A0=C2=A0=C2=A0 nread =3D read_process_output (proc, channel); > =C2=A0=C2=A0=C2=A0 pp =3D XPROCESS(proc); > > nread=3D=3D4095, pp->pid=3D1234 repeatedly. (Actually 1234 seems to be an > arbitrary, but constant number between 1000 and 2000).=20 > > Some more info that I found through strace that might help. > Alltogether read_process_output() is called 214 times and thus a total > of 870k of text is read through /dev/ptmx to read_process_output() . > Could the amount of data possibly explain the slowness? Maybe, if this process IO is emitted non-stop. But this indicates that the traffic is due to the main connection with the main gdb process (which has a positive pid), not with the pty which gdb-mi uses for IO (which has pid -2) like I guessed. Could you do M-: (setq gdb-enable-debug t) RET and show the value of the variable `gdb-debug-log'? For example, when I run M-x gdb on the Emacs binary itself, `gdb-debug-log' gets 22 entries by the time I get to the (gdb) prompt; this is the usual GDB-MI chatter. From the time I "run" the program till the debugged program exits, it gains another 24 entries. Do you see a lot more traffic with your program? From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 08:01:54 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 12:01:54 +0000 Received: from localhost ([127.0.0.1]:40596 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRj73-00056U-O5 for submit@debbugs.gnu.org; Tue, 08 May 2012 08:01:54 -0400 Received: from mail-gg0-f172.google.com ([209.85.161.172]:44863) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRj70-00056H-N1 for 10580@debbugs.gnu.org; Tue, 08 May 2012 08:01:52 -0400 Received: by ggmi1 with SMTP id i1so1387170ggm.3 for <10580@debbugs.gnu.org>; Tue, 08 May 2012 04:59:37 -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=zqSjIHt8jB8cmm79wyHFKCPoC9VCLI2lOac9FUILR64=; b=jejnC1/3ykSt//oVqeq8msfylA5fSLBQ+ky4Rk1ttozxIKAOVo/Iu6X2CxuQOrne9+ GVFGB+MMbV8QAXK8qvobd3AW+y7tJgKmVm4dcDADm5EXcdconhRHd+xbJBbGTyLLjbfM RTudnkHW6WOvOx6Wo6Zni63uIGiPfD1LYwk8wRwrPRX0M57svoPTK1m50om+4lHqELTS GT+MtEA0abo0B34eOiX1EPxDHOh8OAycbNg7oidu9oIZ29DZOIxqncZV6FytOSV9DYtG N10AA1KcRMD1u7pJ9yjeGbm8q4wfm4Y6+09COPEUWv+GHr66xHIQE5q+7v+ogndF1yjA buLQ== MIME-Version: 1.0 Received: by 10.60.21.103 with SMTP id u7mr26437714oee.11.1336478376986; Tue, 08 May 2012 04:59:36 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Tue, 8 May 2012 04:59:36 -0700 (PDT) In-Reply-To: <87mx5j6pqs.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> Date: Tue, 8 May 2012 14:59:36 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8ff1c71ee9092d04bf851ebb X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8ff1c71ee9092d04bf851ebb Content-Type: text/plain; charset=UTF-8 Indeed, my result is much fatter. (safe-length gdb-debug-log) => 223 and the total length of the messages is about 800k. So it seems that the time spent is simply the parsing of this large chunk of data? What gdb command is run that outputs all the file="..." commands? Thanks, Dov On Tue, May 8, 2012 at 11:28 AM, Chong Yidong wrote: > Dov Grobgeld writes: > > > I added the above patch and the result is as follows: > > After the following two lines: > > > > nread = read_process_output (proc, channel); > > pp = XPROCESS(proc); > > > > nread==4095, pp->pid=1234 repeatedly. (Actually 1234 seems to be an > > arbitrary, but constant number between 1000 and 2000). > > > > Some more info that I found through strace that might help. > > Alltogether read_process_output() is called 214 times and thus a total > > of 870k of text is read through /dev/ptmx to read_process_output() . > > Could the amount of data possibly explain the slowness? > > Maybe, if this process IO is emitted non-stop. But this indicates that > the traffic is due to the main connection with the main gdb process > (which has a positive pid), not with the pty which gdb-mi uses for IO > (which has pid -2) like I guessed. > > Could you do > > M-: (setq gdb-enable-debug t) RET > > and show the value of the variable `gdb-debug-log'? > > For example, when I run M-x gdb on the Emacs binary itself, > `gdb-debug-log' gets 22 entries by the time I get to the (gdb) prompt; > this is the usual GDB-MI chatter. From the time I "run" the program > till the debugged program exits, it gains another 24 entries. Do you > see a lot more traffic with your program? > --e89a8ff1c71ee9092d04bf851ebb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Indeed, my resul= t is much fatter.

(safe-length gdb-debug-log) =3D> 223

and= the total length of the messages is about 800k. So it seems that the time = spent is simply the parsing of this large chunk of data? What gdb command i= s run that outputs all the file=3D"..." commands?

Thanks,
Dov

On Tue, May 8, = 2012 at 11:28 AM, Chong Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> I added the above patch and the result is as follows:
> After the following two lines:
>
> =C2=A0=C2=A0=C2=A0 nread =3D read_process_output (proc, channel);
> =C2=A0=C2=A0=C2=A0 pp =3D XPROCESS(proc);
>
> nread=3D=3D4095, pp->pid=3D1234 repeatedly. (Actually 1234 seems to= be an
> arbitrary, but constant number between 1000 and 2000).
>
> Some more info that I found through strace tha= t might help.
> Alltogether read_process_output() is called 214 times and thus a total=
> of 870k of text is read through /dev/ptmx to read_process_output() . > Could the amount of data possibly explain the slowness?

Maybe, if this process IO is emitted non-stop. =C2=A0But this indicat= es that
the traffic is due to the main connection with the main gdb process
(which has a positive pid), not with the pty which gdb-mi uses for IO
(which has pid -2) like I guessed.

Could you do

M-: (setq gdb-enable-debug t) RET

and show the value of the variable `gdb-debug-log'?

For example, when I run M-x gdb on the Emacs binary itself,
`gdb-debug-log' gets 22 entries by the time I get to the (gdb) prompt;<= br> this is the usual GDB-MI chatter. =C2=A0From the time I "run" the= program
till the debugged program exits, it gains another 24 entries. =C2=A0Do you<= br> see a lot more traffic with your program?

--e89a8ff1c71ee9092d04bf851ebb-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 12:27:25 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 16:27:25 +0000 Received: from localhost ([127.0.0.1]:41358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnFz-0002nV-0g for submit@debbugs.gnu.org; Tue, 08 May 2012 12:27:25 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:52061 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRnFw-0002nN-4N for 10580@debbugs.gnu.org; Tue, 08 May 2012 12:27:21 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:55123 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SRnDq-0002SD-Qi; Tue, 08 May 2012 12:25:11 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> Date: Wed, 09 May 2012 00:25:00 +0800 In-Reply-To: (Dov Grobgeld's message of "Tue, 8 May 2012 14:59:36 +0300") Message-ID: <877gwm3ajn.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > Indeed, my result is much fatter. > > (safe-length gdb-debug-log) => 223 > > and the total length of the messages is about 800k. So it seems that > the time spent is simply the parsing of this large chunk of data? What > gdb command is run that outputs all the file="..." commands? Those are status messages from turning on GDB's MI (machine interface) system, I think, though I don't see why it makes so much difference in your case. If you type, from the shell, gdb -i=mi YOUR-BINARY r do you similarly see a huge output? From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 13:43:32 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 17:43:32 +0000 Received: from localhost ([127.0.0.1]:41452 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoRf-0004bx-I1 for submit@debbugs.gnu.org; Tue, 08 May 2012 13:43:32 -0400 Received: from mtaout23.012.net.il ([80.179.55.175]:49943) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoRd-0004bk-VO for 10580@debbugs.gnu.org; Tue, 08 May 2012 13:43:30 -0400 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M3P00400SYV7Q00@a-mtaout23.012.net.il> for 10580@debbugs.gnu.org; Tue, 08 May 2012 20:40:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3P004NHT3Z6F20@a-mtaout23.012.net.il>; Tue, 08 May 2012 20:40:48 +0300 (IDT) Date: Tue, 08 May 2012 20:38:55 +0300 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: X-012-Sender: halo1@inter.net.il To: Dov Grobgeld Message-id: <83vck61sk0.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Tue, 8 May 2012 14:59:36 +0300 > From: Dov Grobgeld > Cc: 10580@debbugs.gnu.org > > Indeed, my result is much fatter. > > (safe-length gdb-debug-log) => 223 > > and the total length of the messages is about 800k. Ouch! could you send it as a compressed attachment? I'd be interested to see what gdb-mi.el commands generate such large output. From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 13:52:08 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 17:52:08 +0000 Received: from localhost ([127.0.0.1]:41458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoZz-0004ob-QQ for submit@debbugs.gnu.org; Tue, 08 May 2012 13:52:07 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:59931) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRoZx-0004o2-32 for 10580@debbugs.gnu.org; Tue, 08 May 2012 13:52:05 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M3P00900TI3MN00@a-mtaout21.012.net.il> for 10580@debbugs.gnu.org; Tue, 08 May 2012 20:49:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3P009S7TJ1GY40@a-mtaout21.012.net.il>; Tue, 08 May 2012 20:49:49 +0300 (IDT) Date: Tue, 08 May 2012 20:47:57 +0300 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: <877gwm3ajn.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: Chong Yidong Message-id: <83txzq1s4y.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10580 Cc: dov.grobgeld@gmail.com, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > From: Chong Yidong > Date: Wed, 09 May 2012 00:25:00 +0800 > Cc: 10580@debbugs.gnu.org > > Those are status messages from turning on GDB's MI (machine interface) > system, I think, though I don't see why it makes so much difference in > your case. > > If you type, from the shell, > > gdb -i=mi YOUR-BINARY > r > > do you similarly see a huge output? As you know, in addition to "run", gdb-mi.el sends lots of other commands behind the scenes, so the above is not a faithful simulation of what happens when GDB is run by Emacs. But I agree that if the above produces similarly voluminous output, we cannot really blame gdb-mi.el. From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 17:09:23 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 21:09:23 +0000 Received: from localhost ([127.0.0.1]:41728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRres-0001mO-IQ for submit@debbugs.gnu.org; Tue, 08 May 2012 17:09:23 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:56648) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrep-0001mC-Qb for 10580@debbugs.gnu.org; Tue, 08 May 2012 17:09:21 -0400 Received: by obbeh20 with SMTP id eh20so10175683obb.3 for <10580@debbugs.gnu.org>; Tue, 08 May 2012 14:07:05 -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=2z2Ud76vkHhYfRx9lPhdt6LrV3zdSbkbCW+PaG7QLsg=; b=QQ3lHKCPSZU/RUdkWYbYfOuT5gxaGexwL4rPqJqMIn2v6pL0+VskvNNRUvr3pdYQJ6 cNTtXqIqbKRgy+t3LAemydxqhADCllbsYDeATten1PR2eYDbRIjL5kkel1zyJxvnnFwb +GKQV92V+B1/vpuE5WkFa7QeEDFNqjRPfjwNKCc0dg/lrWwsLoxnc6LEmlWwsMtwMov6 ocfwvfm9AKl3oe/3lWktpYIK/lNa5l3Hejv7iPceHW8gl9UHOKrAqrIHrEhw733PwDVe oVMp0IsIexS/8v1/eO3g9vfyfQ6PVkXS8h1YARirOwCgGNIg8wWwXBWUMWj16U/71gwf zXEQ== MIME-Version: 1.0 Received: by 10.182.40.71 with SMTP id v7mr54404obk.5.1336511225564; Tue, 08 May 2012 14:07:05 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Tue, 8 May 2012 14:07:05 -0700 (PDT) In-Reply-To: <83txzq1s4y.fsf@gnu.org> References: <20253.9861.848886.122482@fencepost.gnu.org> <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> Date: Wed, 9 May 2012 00:07:05 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Eli Zaretskii Content-Type: multipart/alternative; boundary=f46d04446c11d68d3704bf8cc472 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Chong Yidong , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --f46d04446c11d68d3704bf8cc472 Content-Type: text/plain; charset=UTF-8 So my latest investigations suggest that the problem is the "-file-list-exec-source-files" command which generates the huge output due to the large number of files that is part of the project. The following shows the problem from the command line. echo -file-list-exec-source-files > /tmp/gdb.in gdb MyExec < /tmp/gdb.in > /tmp/gdb.out wc /tmp/gdb.out 11 69 3725105 /tmp/gdb.out (Note that this is on a my home box, where the output is much larger than what I reported this morning possibly due to different paths). So there are still several questions: * Why does it take several minutes to parse a 3.7M file? Could it be related to the fact that gdb-mi/emacs concatinates the entire string before trying to parse it. Still 3.7M is far too much. * Noted that I can't run gdb MyExec < /tmp/gdb.in in a shell buffer. It gets slower and slower while the CPU stays at 100%. * There is a huge redundancy in gdb.out. The command -file-list-exec-source-files should output all source files included, but the same source files are listed multiple times. Consider the huge file size reduction after sorting and uniq'ing: perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb.out | sort | uniq | wc 3931 3931 220654 Why doesn't -file-list-exec-source file do uniq internally. This seems like a bug in gdb. * Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it search for source files on demand? Regards, Dov On Tue, May 8, 2012 at 8:47 PM, Eli Zaretskii wrote: > > From: Chong Yidong > > Date: Wed, 09 May 2012 00:25:00 +0800 > > Cc: 10580@debbugs.gnu.org > > > > Those are status messages from turning on GDB's MI (machine interface) > > system, I think, though I don't see why it makes so much difference in > > your case. > > > > If you type, from the shell, > > > > gdb -i=mi YOUR-BINARY > > r > > > > do you similarly see a huge output? > > As you know, in addition to "run", gdb-mi.el sends lots of other > commands behind the scenes, so the above is not a faithful simulation > of what happens when GDB is run by Emacs. But I agree that if the > above produces similarly voluminous output, we cannot really blame > gdb-mi.el. > > --f46d04446c11d68d3704bf8cc472 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So my latest inv= estigations suggest that the problem is the "-file-list-exec-source-fi= les" command which generates the huge output due to the large number o= f files that is part of the project.

The following shows the problem from the command line.

echo -fil= e-list-exec-source-files > /tmp/gdb.in
= gdb MyExec < /tmp/gdb.in > /tmp/gdb.out=
wc /tmp/gdb.out
=C2=A0=C2=A0=C2=A0=C2=A0 11=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 69 3725105 /tmp/gdb.out

(Note that this is on a my home box, whe= re the output is much larger than what I reported this morning possibly due= to different paths).

So there are still several questions:

* Why does it take several minutes to parse a 3.7M file? Could it be re= lated to the fact that gdb-mi/emacs concatinates the entire string before t= rying to parse it. Still 3.7M is far too much.

* Noted that I can= 9;t run gdb MyExec < /tmp/gdb.in in a shel= l buffer. It gets slower and slower while the CPU stays at 100%.

* There is a huge redundancy in gdb.out. The command -file-list-exec-so= urce-files should output all source files included, but the same source fil= es are listed multiple times. Consider the huge file size reduction after s= orting and uniq'ing:

perl -ne 'while(/(\w+)=3D\"(.*?)\"/g) { print "$1=3D= $2\n"; }' /tmp/gdb.out | sort | uniq | wc

=C2=A0=C2= =A0 3931=C2=A0=C2=A0=C2=A0 3931=C2=A0 220654

Why doesn't -file-l= ist-exec-source file do uniq internally. This seems like a bug in gdb.

* Why does gdb-mi.el do -file= -list-exec-source-files at all? Can't it search for source files on dem= and?

Regards,
Dov

On Tue= , May 8, 2012 at 8:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Chong Yidong <cyd@gnu.org>
> Date: Wed, 09 May 2012 00:25:00 +0800
> Cc: 10580@debbugs.gnu.org=
>
> Those are status messages from turning on GDB's MI (machine interf= ace)
> system, I think, though I don't see why it makes so much differenc= e in
> your case.
>
> If you type, from the shell,
>
> =C2=A0 gdb -i=3Dmi YOUR-BINARY
> =C2=A0 r
>
> do you similarly see a huge output?

As you know, in addition to "run", gdb-mi.el sends lots of = other
commands behind the scenes, so the above is not a faithful simulation
of what happens when GDB is run by Emacs. =C2=A0But I agree that if the
above produces similarly voluminous output, we cannot really blame
gdb-mi.el.


--f46d04446c11d68d3704bf8cc472-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 17:26:56 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 21:26:56 +0000 Received: from localhost ([127.0.0.1]:41740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrvr-0002B4-Pk for submit@debbugs.gnu.org; Tue, 08 May 2012 17:26:56 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:48231) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRrvp-0002As-GX for 10580@debbugs.gnu.org; Tue, 08 May 2012 17:26:54 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3VnDHC0Vw0z4KMhM; Tue, 8 May 2012 23:24:38 +0200 (CEST) Received: from igel.home (ppp-93-104-129-118.dynamic.mnet-online.de [93.104.129.118]) by mail.mnet-online.de (Postfix) with ESMTPA id 3VnDHB67Mtz4KK23; Tue, 8 May 2012 23:24:38 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id 6FD63CA2A9; Tue, 8 May 2012 23:24:38 +0200 (CEST) From: Andreas Schwab To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> X-Yow: --``I love KATRINKA because she drives a PONTIAC. We're going away now. I fed the cat. - Zippy'' Date: Tue, 08 May 2012 23:24:38 +0200 In-Reply-To: (Dov Grobgeld's message of "Wed, 9 May 2012 00:07:05 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , Chong Yidong , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Dov Grobgeld writes: > * Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it > search for source files on demand? Customize gdb-create-source-file-list to nil. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Tue May 08 17:32:27 2012 Received: (at 10580) by debbugs.gnu.org; 8 May 2012 21:32:27 +0000 Received: from localhost ([127.0.0.1]:41745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRs1C-00037Y-RM for submit@debbugs.gnu.org; Tue, 08 May 2012 17:32:27 -0400 Received: from mail-yx0-f172.google.com ([209.85.213.172]:62612) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SRs1A-00037N-F6 for 10580@debbugs.gnu.org; Tue, 08 May 2012 17:32:25 -0400 Received: by yenq13 with SMTP id q13so2005760yen.3 for <10580@debbugs.gnu.org>; Tue, 08 May 2012 14:30:08 -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=lBiKMQzpsTIYPFOudBnddWiIxV4KBT9Nc8M2xxnUAaw=; b=w62zKvayuJcwAwg4h+AcBbyrSMV7xaFpIIqmEJPx/7ILCNZ4+lnmWeFD5EidtuKJ+g FQlwjcNC28nGYjCsKf9Tw6zSfT9h2X2q6KidKFFVkoOpCR+rsBWLgyacWuAe/GhUp/RR pXTbUVQC8JGQaAxAb9+F2jOsSoxhzLvbPvR/udczVaOc5fD4UMPNA2llo82U9CLP/iuq /aGnC7W4SFmPqwLMBH+IegAET2uqHNoWTFTFRwQuu3S04Wd4ONfdkRZ08R4nsrkN0aWA BxLfvP0d5N3zpI+2hnxWXj6rQX7LL3HM43oEyx/fUMLjl2x7j9kXnHJwjwRX2uclsX4n pI1A== MIME-Version: 1.0 Received: by 10.60.169.165 with SMTP id af5mr6039292oec.72.1336512608239; Tue, 08 May 2012 14:30:08 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Tue, 8 May 2012 14:30:08 -0700 (PDT) In-Reply-To: References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> Date: Wed, 9 May 2012 00:30:08 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Andreas Schwab Content-Type: multipart/alternative; boundary=bcaec54a3df4407f4704bf8d17fa X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , Chong Yidong , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --bcaec54a3df4407f4704bf8d17fa Content-Type: text/plain; charset=UTF-8 I first that at first too, but then I realized that it doesn't do it. The gdb-mi.el source has the following logic. (gdb-input ; Needs GDB 6.2 onwards. (list "-file-list-exec-source-files" 'gdb-get-source-file-list)) (if gdb-create-source-file-list (gdb-input ; Needs GDB 6.0 onwards. (list "-file-list-exec-source-file" 'gdb-get-source-file))) i.e. the gdb command "-file-list-exec-source-files" (note the s in files) is called independantly from gdb-create-source-file-list which only influences the execution of "-file-list-exec-source-file". On Wed, May 9, 2012 at 12:24 AM, Andreas Schwab wrote: > Dov Grobgeld writes: > > > * Why does gdb-mi.el do -file-list-exec-source-files at all? Can't it > > search for source files on demand? > > Customize gdb-create-source-file-list to nil. > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." > --bcaec54a3df4407f4704bf8d17fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I first that at = first too, but then I realized that it doesn't do it. The gdb-mi.el sou= rce has the following logic.

=C2=A0 (gdb-input
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; Needs = GDB 6.2 onwards.
=C2=A0=C2=A0 (list "-file-list-exec-source-files" 'gdb-get-so= urce-file-list))
=C2=A0 (if gdb-create-source-file-list
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 (gdb-input
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ; Needs GDB 6.0 onwards.
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (list "-file-list-exec-source-file&q= uot; 'gdb-get-source-file)))

i.e. the gdb command "-file-list-exec-source-files" (note the= s in files) is called independantly from gdb-create-source-file-list which= only influences the execu= tion of "-file-list-exec-source-file".

On Wed, May 9, 2012 at 12:24 AM, Andr= eas Schwab <schwab@linux-m68k.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> * Why does gdb-mi.el do -file-list-exec-source-files at all? Can't= it
> search for source files on demand?

Customize gdb-create-source-file-list to nil.

Andreas.

--
Andreas Schwab, schwab@linux-m68k.= org
GPG Key fingerprint =3D 58CA 54C7 6D53 942B 1756 =C2=A001D3 44D5 214B 8276 = 4ED5
"And now for something completely different."

--bcaec54a3df4407f4704bf8d17fa-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 09 03:49:41 2012 Received: (at 10580) by debbugs.gnu.org; 9 May 2012 07:49:41 +0000 Received: from localhost ([127.0.0.1]:42155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS1eW-000272-R7 for submit@debbugs.gnu.org; Wed, 09 May 2012 03:49:41 -0400 Received: from mail-out.m-online.net ([212.18.0.9]:35359) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS1eV-00026p-4S for 10580@debbugs.gnu.org; Wed, 09 May 2012 03:49:39 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3VnV5k1k0fz4Kh0f; Wed, 9 May 2012 09:47:20 +0200 (CEST) Received: from igel.home (ppp-88-217-114-242.dynamic.mnet-online.de [88.217.114.242]) by mail.mnet-online.de (Postfix) with ESMTPA id 3VnV5h1xkhz4KK30; Wed, 9 May 2012 09:47:20 +0200 (CEST) Received: by igel.home (Postfix, from userid 501) id AFCC2CA2A9; Wed, 9 May 2012 09:47:19 +0200 (CEST) From: Andreas Schwab To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> X-Yow: I appoint you ambassador to Fantasy Island!!! Date: Wed, 09 May 2012 09:47:19 +0200 In-Reply-To: (Dov Grobgeld's message of "Wed, 9 May 2012 00:30:08 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , Chong Yidong , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Dov Grobgeld writes: > I first that at first too, but then I realized that it doesn't do it. The > gdb-mi.el source has the following logic. > > (gdb-input > ; Needs GDB 6.2 onwards. > (list "-file-list-exec-source-files" 'gdb-get-source-file-list)) > (if gdb-create-source-file-list > (gdb-input > ; Needs GDB 6.0 onwards. > (list "-file-list-exec-source-file" 'gdb-get-source-file))) You are looking at a very old version of gdb-mi.el. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Wed May 09 04:46:52 2012 Received: (at 10580) by debbugs.gnu.org; 9 May 2012 08:46:52 +0000 Received: from localhost ([127.0.0.1]:42202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Xr-0004FW-HE for submit@debbugs.gnu.org; Wed, 09 May 2012 04:46:52 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:65175) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SS2Xp-0004FI-4c for 10580@debbugs.gnu.org; Wed, 09 May 2012 04:46:50 -0400 Received: by obbeh20 with SMTP id eh20so32391obb.3 for <10580@debbugs.gnu.org>; Wed, 09 May 2012 01:44:32 -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=t5Ub+COp99vGEKQL59SemF9bAk8dtTlg5AV2ooyiFDg=; b=biraPbnn0LTSBjn9Nu0mKFIj8pGjElud9ctpMZUAdBT6zlKdeCYeJCF6cEqQcPuUli nK6M1KNFpNBWmJD/GTpEUJQkG0pZb8Hdnz58WhmveIX8kBPyoQUfeE6We4rsz29Vvmj6 9bH7Rxjtg3S2e8lmY2tOy5t8w7X+g2YYWjZNNY7wzI5G1MbNKxQzpZCZmgiAnd2/c83s q7TlLDP10ffC+1w02HuxrFl2RCJnmAGxXx2zmdIJXCzNMatOPzKxMfk4GD7L3XiiB9Pn nUjoC1BOtq6dSDT2HOFyG8AKcydTv3mpxzUTgfnrV+Z1SchMJ8RBgWPrHO87/MEEa1qD o0JA== MIME-Version: 1.0 Received: by 10.60.29.39 with SMTP id g7mr8086383oeh.6.1336553072337; Wed, 09 May 2012 01:44:32 -0700 (PDT) Received: by 10.182.60.137 with HTTP; Wed, 9 May 2012 01:44:32 -0700 (PDT) In-Reply-To: References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> Date: Wed, 9 May 2012 11:44:32 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Andreas Schwab Content-Type: multipart/alternative; boundary=e89a8ff2563219a17604bf96831b X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , Chong Yidong , 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8ff2563219a17604bf96831b Content-Type: text/plain; charset=UTF-8 Yes, sorry. I discovered that I looked at an old version. The latest git version indeed allows disabling the -file-list-exec-source-files. I will use that option which indeed is a work around for the problem. In addition, I filed a bug for gdb that it should uniq the filenames output by -file-list-exec-source-files. I realized that all filelist-exec-source-files is used for is to turn on gdb minor mode for all files that are currently open in emacs. Perhaps we should turn the problem around by asking for a gdb function that answers the question whether a file is referenced by an executable. It would then be possible to loop over the emacs buffers and turn on gdb minor mode if the file is referenced by the new gdb session. Regards, Dov On Wed, May 9, 2012 at 10:47 AM, Andreas Schwab wrote: > Dov Grobgeld writes: > > > I first that at first too, but then I realized that it doesn't do it. The > > gdb-mi.el source has the following logic. > > > > (gdb-input > > ; Needs GDB 6.2 onwards. > > (list "-file-list-exec-source-files" 'gdb-get-source-file-list)) > > (if gdb-create-source-file-list > > (gdb-input > > ; Needs GDB 6.0 onwards. > > (list "-file-list-exec-source-file" 'gdb-get-source-file))) > > You are looking at a very old version of gdb-mi.el. > > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." > --e89a8ff2563219a17604bf96831b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, sorry. I di= scovered that I looked at an old version. The latest git version indeed all= ows disabling the -file-list-exec-source-files. I will use that option whic= h indeed is a work around for the problem.

In addition, I filed a bug for gdb that it should uniq the filenames ou= tput by -file-list-exec-source-files.

I realized that all filelist-= exec-source-files is used for is to turn on gdb minor mode for all files th= at are currently open in emacs. Perhaps we should turn the problem around b= y asking for a gdb function that answers the question whether a file is ref= erenced by an executable. It would then be possible to loop over the emacs = buffers and turn on gdb minor mode if the file is referenced by the new gdb= session.

Regards,
Dov

On Wed, May 9,= 2012 at 10:47 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:
> I first that at first too, but then I realized that it doesn't do = it. The
> gdb-mi.el source has the following logic.
>
> =C2=A0 (gdb-input
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; Nee= ds GDB 6.2 onwards.
> =C2=A0 =C2=A0(list "-file-list-exec-source-files" 'gdb-g= et-source-file-list))
> =C2=A0 (if gdb-create-source-file-list
> =C2=A0 =C2=A0 =C2=A0 (gdb-input
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; Nee= ds GDB 6.0 onwards.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(list "-file-list-exec-source-file&quo= t; 'gdb-get-source-file)))

You are looking at a very old version of gdb-mi.el.

Andreas.

--
Andreas Schwab, schwab@linux-m68k.= org
GPG Key fingerprint =3D 58CA 54C7 6D53 942B 1756 =C2=A001D3 44D5 214B 8276 = 4ED5
"And now for something completely different."

--e89a8ff2563219a17604bf96831b-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 09 13:40:27 2012 Received: (at 10580) by debbugs.gnu.org; 9 May 2012 17:40:27 +0000 Received: from localhost ([127.0.0.1]:43488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAsF-0003dD-9D for submit@debbugs.gnu.org; Wed, 09 May 2012 13:40:27 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:48167) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSAsC-0003cy-TX for 10580@debbugs.gnu.org; Wed, 09 May 2012 13:40:26 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M3R00I00NKDN400@a-mtaout21.012.net.il> for 10580@debbugs.gnu.org; Wed, 09 May 2012 20:38:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3R00IX4NNFHL50@a-mtaout21.012.net.il>; Wed, 09 May 2012 20:38:04 +0300 (IDT) Date: Wed, 09 May 2012 20:36:14 +0300 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: X-012-Sender: halo1@inter.net.il To: Dov Grobgeld Message-id: <837gwl1ckx.fsf@gnu.org> References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Wed, 9 May 2012 11:44:32 +0300 > From: Dov Grobgeld > Cc: Eli Zaretskii , Chong Yidong , 10580@debbugs.gnu.org > > In addition, I filed a bug for gdb that it should uniq the filenames output > by -file-list-exec-source-files. Can you provide a link to that bug report? FWIW, when I use -file-list-exec-source-files while debugging Emacs, I don't see duplicate file names in the GDB output. Maybe I'm blind. From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 02:03:17 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 06:03:17 +0000 Received: from localhost ([127.0.0.1]:44035 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSMT6-00004w-R4 for submit@debbugs.gnu.org; Thu, 10 May 2012 02:03:17 -0400 Received: from mail-ob0-f172.google.com ([209.85.214.172]:55241) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSMT4-0008WP-03 for 10580@debbugs.gnu.org; Thu, 10 May 2012 02:03:15 -0400 Received: by obbeh20 with SMTP id eh20so1424349obb.3 for <10580@debbugs.gnu.org>; Wed, 09 May 2012 23:00:49 -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=C8KhhmHSJ4kY1vukW0WfrU0wlgu7FSyOxw6lNpUL97k=; b=lIKsLZcSDJwy+l9q9vJy1iIDzhXVJEZnEoAOnL6yj3MmbxzzGVlei+6G2V5SZxn76q tiY5q4JBAaW8R3oS/dCO8PZSQcbLD3ilDSDzmd2aVeMhP1iWEPDkEGq1XaokBQQmzimO 9iWmJlVUvlXORahaFYHMp+LhDOFra9U+ysa2p/Qmi0tqNkt5Fqz4dECoR+JHdPWJF98t /Vy+B2HrqZDBV6m7jJvARStJcpbSI1yeArVTsXeX9QnnOZ3ljKROP6Y5UFBcArJfS9FX hMq6FCPq0xCxZRxBqIaFM9od8GmoY2TMmivNfYHaePe5KzKTgBASfI+mllcoSRUOAyMI 0RYg== MIME-Version: 1.0 Received: by 10.60.3.6 with SMTP id 6mr3993840oey.35.1336629649753; Wed, 09 May 2012 23:00:49 -0700 (PDT) Received: by 10.182.19.137 with HTTP; Wed, 9 May 2012 23:00:49 -0700 (PDT) In-Reply-To: <837gwl1ckx.fsf@gnu.org> References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> Date: Thu, 10 May 2012 09:00:49 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Eli Zaretskii Content-Type: multipart/alternative; boundary=e89a8fb2028278481204bfa8578e X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8fb2028278481204bfa8578e Content-Type: text/plain; charset=UTF-8 Here is a link to the gdb bug: http://sourceware.org/bugzilla/show_bug.cgi?id=14081 I tried running file-list-exec-source-files and I get duplicates as well. Try the following: prompt> echo -file-list-exec-source-files > /tmp/gdb.in prompt> gdb -i=mi emacs < /tmp/gdb.in > /tmp/gdb.out prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb.out | sort | head -15 file=alloc.c file=alloc.c file=allocator.c file=atimer.c file=atimer.c file=bidi.c file=bidi.c file=buffer.c file=buffer.c file=buffer.h file=buffer.h file=buffer.h file=buffer.h file=buffer.h file=buffer.h My version of gdb is: GNU gdb (GDB) Fedora (7.2-52.fc14) For my executable gdb outputs full paths as well as the fullname field, which expands the output considerably. Still, it bothering me the fact that the above perl expression parses the gdb output in a fraction of a second, (0.01s user time) whereas gdb-mi.el takes more than 40s. Regards, Dov On Wed, May 9, 2012 at 8:36 PM, Eli Zaretskii wrote: > > Date: Wed, 9 May 2012 11:44:32 +0300 > > From: Dov Grobgeld > > Cc: Eli Zaretskii , Chong Yidong , > 10580@debbugs.gnu.org > > > > In addition, I filed a bug for gdb that it should uniq the filenames > output > > by -file-list-exec-source-files. > > Can you provide a link to that bug report? > > FWIW, when I use -file-list-exec-source-files while debugging Emacs, I > don't see duplicate file names in the GDB output. Maybe I'm blind. > --e89a8fb2028278481204bfa8578e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is a link t= o the gdb bug:

http://sourceware.org/bugzilla/show_bug.cgi?id=3D14081
I tried running file-= list-exec-source-files and I get duplicates as well. Try the following:

prompt> echo -file-list-exec-source-files > /tmp/gdb.in
prompt> gdb -i=3Dmi emacs < /tmp/gdb.in > /tmp/gdb.out
prompt> perl -ne &#= 39;while(/(\w+)=3D\"(.*?)\"/g) { print "$1=3D$2\n"; }&#= 39; /tmp/gdb.out | sort | head -15
file=3Dalloc.c
file=3Dalloc.c
file=3Dallocator.c
file=3Datimer.cfile=3Datimer.c
file=3Dbidi.c
file=3Dbidi.c
file=3Dbuffer.c
f= ile=3Dbuffer.c
file=3Dbuffer.h
file=3Dbuffer.h
file=3Dbuffer.h
= file=3Dbuffer.h
file=3Dbuffer.h
file=3Dbuffer.h

My version of gdb is:

GNU gdb (GDB) Fedora (7= .2-52.fc14)

For my executable gdb outputs full paths as well as the = fullname field, which expands the output considerably.

Still, it bo= thering me the fact that the above perl expression parses the gdb output in= a fraction of a second, (0.01s user time) whereas gdb-mi.el takes more tha= n 40s.

Regards,
Dov

On Wed, May 9, 2012 a= t 8:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Wed, 9 May 2012 11:44:32 +0300
> From: Dov Grobgeld <dov.g= robgeld@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org= >, Chong Yidong <cyd@gnu.org>, = 10580@debbugs.gnu.org
>
> In addition, I filed a bug for gdb that it should uniq the filenames o= utput
> by -file-list-exec-source-files.

Can you provide a link to that bug report?

FWIW, when I use -file-list-exec-source-files while debugging Emacs, I
don't see duplicate file names in the GDB output. =C2=A0Maybe I'm b= lind.

--e89a8fb2028278481204bfa8578e-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 10:16:10 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 14:16:10 +0000 Received: from localhost ([127.0.0.1]:44940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUA5-00063m-Qy for submit@debbugs.gnu.org; Thu, 10 May 2012 10:16:10 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:58981 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSUA2-00063e-RL for 10580@debbugs.gnu.org; Thu, 10 May 2012 10:16:07 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:41142 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SSU7m-0008NH-1d; Thu, 10 May 2012 10:13:46 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> Date: Thu, 10 May 2012 22:13:36 +0800 In-Reply-To: (Dov Grobgeld's message of "Thu, 10 May 2012 09:00:49 +0300") Message-ID: <87pqacrunj.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , 10580@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Dov Grobgeld writes: > Still, it bothering me the fact that the above perl expression parses > the gdb output in a fraction of a second, (0.01s user time) whereas > gdb-mi.el takes more than 40s. I would also like to learn more about where the bottleneck is. Could you do the following: M-: (require 'gdb-mi) RET M-: (defun gdb-get-source-file-list () nil) RET then run M-x gdb as usual, and see if that makes any difference in performance? Leave gdb-create-source-file-list set at t. (The above steps cause gdb-mi to issue the -file-list-exec-source-files command and read the output, as usual, but skip parsing the output into the source file list.) From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 12:34:10 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 16:34:10 +0000 Received: from localhost ([127.0.0.1]:47007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWJc-0000JY-Un for submit@debbugs.gnu.org; Thu, 10 May 2012 12:34:09 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:56884) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSWJV-0000Iy-3n for 10580@debbugs.gnu.org; Thu, 10 May 2012 12:34:06 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3T00500EE9MY00@a-mtaout22.012.net.il> for 10580@debbugs.gnu.org; Thu, 10 May 2012 19:33:54 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3T004QVFCEXYF0@a-mtaout22.012.net.il>; Thu, 10 May 2012 19:33:51 +0300 (IDT) Date: Thu, 10 May 2012 19:32:04 +0300 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: X-012-Sender: halo1@inter.net.il To: Dov Grobgeld Message-id: <83ipg4yp2z.fsf@gnu.org> References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Thu, 10 May 2012 09:00:49 +0300 > From: Dov Grobgeld > Cc: schwab@linux-m68k.org, cyd@gnu.org, 10580@debbugs.gnu.org > > I tried running file-list-exec-source-files and I get duplicates as well. > Try the following: > > prompt> echo -file-list-exec-source-files > /tmp/gdb.in > prompt> gdb -i=mi emacs < /tmp/gdb.in > /tmp/gdb.out > prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' > /tmp/gdb.out | sort | head -15 > file=alloc.c > file=alloc.c > file=allocator.c > file=atimer.c > file=atimer.c > file=bidi.c > file=bidi.c > file=buffer.c > file=buffer.c > file=buffer.h > file=buffer.h > file=buffer.h > file=buffer.h > file=buffer.h > file=buffer.h I don't see anything like that. Here's my output: addr=0x011b4ea5 addr=0x011b4ea5 addr=0x012329a8 disp=del disp=del disp=keep enabled=y enabled=y enabled=y file=../lib/allocator.h file=../lib/careadlinkat.h file=../lib/ignore-value.h file=../lib/intprops.h file=../lib/intprops.h file=../lib/intprops.h IOW, all the duplicates I see are header files. Not a single .c file shows up, not even if I change "head -15" into "head -100". > My version of gdb is: > > GNU gdb (GDB) Fedora (7.2-52.fc14) Maybe you should upgrade, I dunno. I use 7.4.1, FWIW. Or maybe GCC versions later than what I have do that. > For my executable gdb outputs full paths as well as the fullname field, > which expands the output considerably. Here too, but that's expected (and necessary). From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 14:43:51 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 18:43:51 +0000 Received: from localhost ([127.0.0.1]:47107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYL8-0004FK-3P for submit@debbugs.gnu.org; Thu, 10 May 2012 14:43:50 -0400 Received: from mail-yw0-f44.google.com ([209.85.213.44]:58750) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYL5-0004F5-5h for 10580@debbugs.gnu.org; Thu, 10 May 2012 14:43:48 -0400 Received: by yhq56 with SMTP id 56so1746873yhq.3 for <10580@debbugs.gnu.org>; Thu, 10 May 2012 11:43:40 -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=tVpmo6sc+mfbfo9FvFOVWvIM2luGi6UVTaS+YIvKKSw=; b=Z4hbzjaE8l4uk5yVDEHt0kQEO65rcqNKT+5k9+T5p/TUJ/E3LNRR27qKm9s+gSScep o1CZTyQbW9IijqUYA+Z6tA2n3k++koTXc6644iGnFsohZ6GUz5Wui+RcQKBR1Jp8K3Zi 9YQt5yRYnVZ+Y+3L+NQs98BbL8dewu0gWfNCbz93lusu5bqnv7NKu7aBV2w+PBw7ZEOO DZ0PXt+WqfXdJclHAJR6TsIE0B2LEjKoRnyI/fm3fimteKb/OXBYGF/GlvYxADvisIk3 rmL0/Xcj+sD1paGZ2AGTk0rZvx3BkRIhhrn1CGJXoWGnpe6+cmG2rFMAHgshcP7vLO8g y06Q== MIME-Version: 1.0 Received: by 10.60.3.6 with SMTP id 6mr7357543oey.35.1336675419833; Thu, 10 May 2012 11:43:39 -0700 (PDT) Received: by 10.182.19.137 with HTTP; Thu, 10 May 2012 11:43:39 -0700 (PDT) In-Reply-To: <83ipg4yp2z.fsf@gnu.org> References: <87aa1mj69x.fsf@gnu.org> <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <83ipg4yp2z.fsf@gnu.org> Date: Thu, 10 May 2012 21:43:39 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Eli Zaretskii Content-Type: multipart/alternative; boundary=e89a8fb2028294473404bfb2ffec X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8fb2028294473404bfb2ffec Content-Type: text/plain; charset=UTF-8 I just downloaded gdb from cvs and tried with the latest version and there are still duplicates. Perhaps it is because of gcc? But on the positive side there is indeed a huge difference in the gdb output. prompt> gdb --version GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16) prompt> /usr/local/public-dev/bin/gdb --version GNU gdb (GDB) 7.4.50.20120509-cvs prompt> gdb -i=mi MyExec < /tmp/gdb.in > /tmp/gdb-old.out prompt> /usr/local/public-dev/bin/gdb -i=mi MyExec < /tmp/gdb.in > /tmp/gdb-new.out prompt> ls -1s --block-size=1 /tmp/gdb*.out 884736 /tmp/gdb-new.out 3727360 /tmp/gdb-old.out prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb-old.out | sort | wc 67311 67311 3522494 prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb-new.out | sort | wc 14221 14221 837082 prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb-old.out | sort |uniq| wc 3931 3931 220654 prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' /tmp/gdb-new.out | sort |uniq| wc 2245 2245 137404 But even the factor 837k vs 137k is substantial, so it is still valid to do an internal uniq within gdb. I'll try to put together a patch. Regards, Dov On Thu, May 10, 2012 at 7:32 PM, Eli Zaretskii wrote: > > Date: Thu, 10 May 2012 09:00:49 +0300 > > From: Dov Grobgeld > > Cc: schwab@linux-m68k.org, cyd@gnu.org, 10580@debbugs.gnu.org > > > > I tried running file-list-exec-source-files and I get duplicates as well. > > Try the following: > > > > prompt> echo -file-list-exec-source-files > /tmp/gdb.in > > prompt> gdb -i=mi emacs < /tmp/gdb.in > /tmp/gdb.out > > prompt> perl -ne 'while(/(\w+)=\"(.*?)\"/g) { print "$1=$2\n"; }' > > /tmp/gdb.out | sort | head -15 > > file=alloc.c > > file=alloc.c > > file=allocator.c > > file=atimer.c > > file=atimer.c > > file=bidi.c > > file=bidi.c > > file=buffer.c > > file=buffer.c > > file=buffer.h > > file=buffer.h > > file=buffer.h > > file=buffer.h > > file=buffer.h > > file=buffer.h > > I don't see anything like that. Here's my output: > > addr=0x011b4ea5 > addr=0x011b4ea5 > addr=0x012329a8 > disp=del > disp=del > disp=keep > enabled=y > enabled=y > enabled=y > file=../lib/allocator.h > file=../lib/careadlinkat.h > file=../lib/ignore-value.h > file=../lib/intprops.h > file=../lib/intprops.h > file=../lib/intprops.h > > IOW, all the duplicates I see are header files. Not a single .c file > shows up, not even if I change "head -15" into "head -100". > > > My version of gdb is: > > > > GNU gdb (GDB) Fedora (7.2-52.fc14) > > Maybe you should upgrade, I dunno. I use 7.4.1, FWIW. > > Or maybe GCC versions later than what I have do that. > > > For my executable gdb outputs full paths as well as the fullname field, > > which expands the output considerably. > > Here too, but that's expected (and necessary). > --e89a8fb2028294473404bfb2ffec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just downloade= d gdb from cvs and tried with the latest version and there are still duplic= ates. Perhaps it is because of gcc? But on the positive side there is indee= d a huge difference in the gdb output.

prompt> gdb --version
GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc= 16)
prompt> /usr/local/public-dev/bin/gdb --version
GNU gdb (GDB) = 7.4.50.20120509-cvs
prompt> gdb -i=3Dmi MyExec < /tmp/gdb.in > /tmp/gdb-old.out
prompt> /usr/local/public-dev/bin/gdb -i=3Dmi MyExec < /tmp/gdb.in > /tmp/gdb-new.out
prompt> ls -1s --= block-size=3D1 /tmp/gdb*.out
=C2=A0884736 /tmp/gdb-new.out
3727360 /t= mp/gdb-old.out
prompt> perl -ne 'while(/(\w+)=3D\"(.*?)\"/g) { print &quo= t;$1=3D$2\n"; }' /tmp/gdb-old.out | sort | wc
=C2=A0 67311=C2= =A0=C2=A0 67311 3522494
prompt> perl -ne 'while(/(\w+)=3D\"(= .*?)\"/g) { print "$1=3D$2\n"; }' /tmp/gdb-new.out | sor= t | wc
=C2=A0 14221=C2=A0=C2=A0 14221=C2=A0 837082
prompt> perl -ne 'whi= le(/(\w+)=3D\"(.*?)\"/g) { print "$1=3D$2\n"; }' /t= mp/gdb-old.out | sort |uniq| wc
=C2=A0=C2=A0 3931=C2=A0=C2=A0=C2=A0 393= 1=C2=A0 220654
prompt> perl -ne 'while(/(\w+)=3D\"(.*?)\&quo= t;/g) { print "$1=3D$2\n"; }' /tmp/gdb-new.out | sort |uniq| = wc
=C2=A0=C2=A0 2245=C2=A0=C2=A0=C2=A0 2245=C2=A0 137404

But eve= n the factor 837k vs 137k is substantial, so it is still valid to do an int= ernal uniq within gdb. I'll try to put together a patch.

Regards= ,
Dov

On Thu, May 10, 2012 at 7:32 PM, Eli Zaretskii <eliz@gnu.org> wro= te:
> Date: Thu, 10 May 2012 09:00:49 +0300
> From: Dov Grobgeld <dov.g= robgeld@gmail.com>
> Cc: schwab@linux-m68k.org= , cyd@gnu.org, 10580@debbugs.gnu.org
>
> I tried running file-list-exec-source-files and I get duplicates as we= ll.
> Try the following:
>
> prompt> echo -file-list-exec-source-files > /tmp/gdb.in
> prompt> gdb -i=3Dmi emacs < /tmp/gdb.in > /tmp/gdb.out
> prompt> perl -ne 'while(/(\w+)=3D\"(.*?)\"/g) { print= "$1=3D$2\n"; }'
> /tmp/gdb.out | sort | head -15
> file=3Dalloc.c
> file=3Dalloc.c
> file=3Dallocator.c
> file=3Datimer.c
> file=3Datimer.c
> file=3Dbidi.c
> file=3Dbidi.c
> file=3Dbuffer.c
> file=3Dbuffer.c
> file=3Dbuffer.h
> file=3Dbuffer.h
> file=3Dbuffer.h
> file=3Dbuffer.h
> file=3Dbuffer.h
> file=3Dbuffer.h

I don't see anything like that. =C2=A0Here's my output:

=C2=A0addr=3D0x011b4ea5
=C2=A0addr=3D0x011b4ea5
=C2=A0addr=3D0x012329a8
=C2=A0disp=3Ddel
=C2=A0disp=3Ddel
=C2=A0disp=3Dkeep
=C2=A0enabled=3Dy
=C2=A0enabled=3Dy
=C2=A0enabled=3Dy
=C2=A0file=3D../lib/allocator.h
=C2=A0file=3D../lib/careadlinkat.h
=C2=A0file=3D../lib/ignore-value.h
=C2=A0file=3D../lib/intprops.h
=C2=A0file=3D../lib/intprops.h
=C2=A0file=3D../lib/intprops.h

IOW, all the duplicates I see are header files. =C2=A0Not a single .c file<= br> shows up, not even if I change "head -15" into "head -100&qu= ot;.

> My version of gdb is:
>
> GNU gdb (GDB) Fedora (7.2-52.fc14)

Maybe you should upgrade, I dunno. =C2=A0I use 7.4.1, FWIW.

Or maybe GCC versions later than what I have do that.

> For my executable gdb outputs full paths as well as the fullname field= ,
> which expands the output considerably.

Here too, but that's expected (and necessary).

--e89a8fb2028294473404bfb2ffec-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 15:07:51 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 19:07:51 +0000 Received: from localhost ([127.0.0.1]:47117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYiM-0004oV-Ka for submit@debbugs.gnu.org; Thu, 10 May 2012 15:07:50 -0400 Received: from mail-qc0-f172.google.com ([209.85.216.172]:33195) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSYiK-0004oF-SN for 10580@debbugs.gnu.org; Thu, 10 May 2012 15:07:49 -0400 Received: by qcsq13 with SMTP id q13so1493211qcs.3 for <10580@debbugs.gnu.org>; Thu, 10 May 2012 12:07:41 -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=kxKyibFv5tfnYA6wZeQjC9oaYPkyBqEWia6+XEuCoDA=; b=CaFXiJnrADaR+sbjy8nsV+VbdWaLfIRZYFBk1ApCp4gpwG/ojIDooYjtf3ekjmyFv0 AuQECxK54GA6jYqFFDlbVLn2o93UyxmpmnEN03mboVNif3SGCWzT4o1lTvQhhJG2L3rP Z1Pw2BOWVbT2JoE1Bpb7sgPmyHH8bQMOva0Pa9Aa1/aRWYSnVsqADXpuyws1NrgQJDh9 KNsGdP4pc7H15GmMWTAVOedF7aTwqTxo/R8NCCRcUuO/MYff1cx+8OcrURy3GNDJIRZt EvVVApQRqL7/A+TtvNh5+Y3hPBRQKvZIKzarQ7om4BnKpHuhP8/hKYWIr4VjcwdYd8QT ohUQ== MIME-Version: 1.0 Received: by 10.60.1.67 with SMTP id 3mr7630727oek.15.1336676859090; Thu, 10 May 2012 12:07:39 -0700 (PDT) Received: by 10.182.19.137 with HTTP; Thu, 10 May 2012 12:07:38 -0700 (PDT) In-Reply-To: <87pqacrunj.fsf@gnu.org> References: <87havtvpeb.fsf@gnu.org> <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> Date: Thu, 10 May 2012 22:07:38 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=e89a8fb1fe205d95db04bfb35576 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , 10580@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --e89a8fb1fe205d95db04bfb35576 Content-Type: text/plain; charset=UTF-8 Here are the tests when using the the latest cvs gdb that yields a gdb output file of about 800k. Without gdb-get-source-file-list override: ~139s With gdb-get-source-file-list override: ~125s Thus it is clear that most of the time is taken just reading the string into emacs. But doing find-file on the same file is almost instantaneous. Regards, Dov On Thu, May 10, 2012 at 5:13 PM, Chong Yidong wrote: > Dov Grobgeld writes: > > > Still, it bothering me the fact that the above perl expression parses > > the gdb output in a fraction of a second, (0.01s user time) whereas > > gdb-mi.el takes more than 40s. > > I would also like to learn more about where the bottleneck is. > > Could you do the following: > > M-: (require 'gdb-mi) RET > M-: (defun gdb-get-source-file-list () nil) RET > > then run M-x gdb as usual, and see if that makes any difference in > performance? Leave gdb-create-source-file-list set at t. > > (The above steps cause gdb-mi to issue the -file-list-exec-source-files > command and read the output, as usual, but skip parsing the output into > the source file list.) > --e89a8fb1fe205d95db04bfb35576 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are the tes= ts when using the the latest cvs gdb that yields a gdb output file of about= 800k.

Without gdb-get-source-file-list override: ~139s
With gdb-= get-source-file-list override: ~125s

Thus it is clear that most of the time is taken just reading the string= into emacs. But doing find-file on the same file is almost instantaneous.<= br>
Regards,
Dov


On Thu,= May 10, 2012 at 5:13 PM, Chong Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:
> Still, it bothering me the fact that the above perl expression parses<= br> > the gdb output in a fraction of a second, (0.01s user time) whereas > gdb-mi.el takes more than 40s.

I would also like to learn more about where the bottleneck is.

Could you do the following:

M-: (require 'gdb-mi) RET
M-: (defun gdb-get-source-file-list () nil) RET

then run M-x gdb as usual, and see if that makes any difference in
performance? =C2=A0Leave gdb-create-source-file-list set at t.

(The above steps cause gdb-mi to issue the -file-list-exec-source-files
command and read the output, as usual, but skip parsing the output into
the source file list.)

--e89a8fb1fe205d95db04bfb35576-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 10 16:26:10 2012 Received: (at 10580) by debbugs.gnu.org; 10 May 2012 20:26:10 +0000 Received: from localhost ([127.0.0.1]:47157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZw9-0007QL-Vo for submit@debbugs.gnu.org; Thu, 10 May 2012 16:26:10 -0400 Received: from ironport-out.teksavvy.com ([206.248.143.162]:36111) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSZw7-0007Q8-Gw for 10580@debbugs.gnu.org; Thu, 10 May 2012 16:26:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYIACxOgk9FpYsJ/2dsb2JhbABDuCMDgQyBCIIJAQEEAVYjBQsLNBIUGA0kiBwFC7Yni2GEeQSWfY1IgV2DAw X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="179520886" Received: from 69-165-139-9.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.9]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 May 2012 16:26:00 -0400 Received: by pastel.home (Postfix, from userid 20848) id E305F59015; Thu, 10 May 2012 16:25:59 -0400 (EDT) From: Stefan Monnier To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU Message-ID: References: <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> Date: Thu, 10 May 2012 16:25:59 -0400 In-Reply-To: (Dov Grobgeld's message of "Thu, 10 May 2012 22:07:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: 10580 Cc: tomo@cx4a.org, Chong Yidong , schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > Here are the tests when using the the latest cvs gdb that yields a gdb > output file of about 800k. > Without gdb-get-source-file-list override: ~139s > With gdb-get-source-file-list override: ~125s > Thus it is clear that most of the time is taken just reading the string > into emacs. But doing find-file on the same file is almost instantaneous. Sounds like a perfect test case for the native elisp profiler (a prototype of which is at http://cx4a.org/hack/emacs-native-profiler.html, and hopefully it will mature over the summer since it's funded as a GSoC). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri May 11 02:34:11 2012 Received: (at 10580) by debbugs.gnu.org; 11 May 2012 06:34:11 +0000 Received: from localhost ([127.0.0.1]:47461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSjQX-0004oh-5l for submit@debbugs.gnu.org; Fri, 11 May 2012 02:34:10 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:47541 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSjQT-0004oV-3p for 10580@debbugs.gnu.org; Fri, 11 May 2012 02:34:06 -0400 Received: from [155.69.16.143] (port=38908 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SSjQM-0006Mj-Kn; Fri, 11 May 2012 02:33:59 -0400 From: Chong Yidong To: Dov Grobgeld Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> Date: Fri, 11 May 2012 14:33:52 +0800 In-Reply-To: (Dov Grobgeld's message of "Thu, 10 May 2012 22:07:38 +0300") Message-ID: <8762c3z0of.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , 10580@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) --=-=-= Content-Type: text/plain Dov Grobgeld writes: > Here are the tests when using the the latest cvs gdb that yields a gdb > output file of about 800k. > > Without gdb-get-source-file-list override: ~139s > With gdb-get-source-file-list override: ~125s > > Thus it is clear that most of the time is taken just reading the > string into emacs. But doing find-file on the same file is almost > instantaneous. Here's another little experiment. Could you apply the two attached patches, individually, and see what difference each patch makes? (Again, with gdb-create-source-file-list at its default of t, and without any other patches to gdb-mi.el.) --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=gdb-test-1.patch === modified file 'lisp/progmodes/gdb-mi.el' *** lisp/progmodes/gdb-mi.el 2012-04-20 10:09:40 +0000 --- lisp/progmodes/gdb-mi.el 2012-05-11 06:21:29 +0000 *************** *** 1918,1923 **** --- 1918,1925 ---- (gdb-ignored-notification . "=[-[:alpha:]]+,?\\(.*?\\)\n") (gdb-shell . "\\(\\(?:^.+\n\\)+\\)"))) + (defvar gdb-accumulator nil) + (defun gud-gdbmi-marker-filter (string) "Filter GDB/MI output." *************** *** 1928,1954 **** (> (length gdb-debug-log) gdb-debug-log-max)) (setcdr (nthcdr (1- gdb-debug-log-max) gdb-debug-log) nil))) ! ;; Recall the left over gud-marker-acc from last time ! (setq gud-marker-acc (concat gud-marker-acc string)) ;; Start accumulating output for the GUD buffer (setq gdb-filter-output "") - (let (output-record-list) ! ;; Process all the complete markers in this chunk. ! (dolist (gdbmi-record gdbmi-record-list) ! (while (string-match (cdr gdbmi-record) gud-marker-acc) ! (push (list (match-beginning 0) ! (car gdbmi-record) ! (match-string 1 gud-marker-acc) ! (match-string 2 gud-marker-acc) ! (match-end 0)) ! output-record-list) ! (setq gud-marker-acc ! (concat (substring gud-marker-acc 0 (match-beginning 0)) ! ;; Pad with spaces to preserve position. ! (make-string (length (match-string 0 gud-marker-acc)) 32) ! (substring gud-marker-acc (match-end 0)))))) (setq output-record-list (sort output-record-list 'gdb-car<)) --- 1930,1960 ---- (> (length gdb-debug-log) gdb-debug-log-max)) (setcdr (nthcdr (1- gdb-debug-log-max) gdb-debug-log) nil))) ! ;; Recall the left over output from last time ! (unless gdb-accumulator ! (setq gdb-accumulator (get-buffer-create " *gdb output accumulator"))) ! ! (with-current-buffer gdb-accumulator ! (goto-char (point-max)) ! (insert string)) ;; Start accumulating output for the GUD buffer (setq gdb-filter-output "") ! ;; Process all the complete markers in this chunk. ! (let (output-record-list marker) ! (with-current-buffer gdb-accumulator ! (dolist (gdbmi-record gdbmi-record-list) ! (goto-char (point-min)) ! (while (re-search-forward (cdr gdbmi-record) nil t) ! (setq marker (make-marker)) ! (set-marker marker (match-beginning 0)) ! (push (list marker ! (car gdbmi-record) ! (match-string 1) ! (match-string 2)) ! output-record-list) ! (replace-match "\n")))) (setq output-record-list (sort output-record-list 'gdb-car<)) *************** *** 1969,1976 **** (setq gdb-output-sink 'user) ;; Remove padding. ! (string-match "^ *" gud-marker-acc) ! (setq gud-marker-acc (substring gud-marker-acc (match-end 0))) gdb-filter-output)) --- 1975,1984 ---- (setq gdb-output-sink 'user) ;; Remove padding. ! (with-current-buffer gdb-accumulator ! (goto-char (point-min)) ! (while (re-search-forward "^\n" nil t) ! (replace-match ""))) gdb-filter-output)) --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=gdb-test-2.patch === modified file 'lisp/progmodes/gdb-mi.el' *** lisp/progmodes/gdb-mi.el 2012-04-20 10:09:40 +0000 --- lisp/progmodes/gdb-mi.el 2012-05-11 06:32:52 +0000 *************** *** 1904,1923 **** (< (car a) (car b))) (defvar gdbmi-record-list ! '((gdb-gdb . "(gdb) \n") ! (gdb-done . "\\([0-9]*\\)\\^done,?\\(.*?\\)\n") ! (gdb-starting . "\\([0-9]*\\)\\^running\n") ! (gdb-error . "\\([0-9]*\\)\\^error,\\(.*?\\)\n") ! (gdb-console . "~\\(\".*?\"\\)\n") ! (gdb-internals . "&\\(\".*?\"\\)\n") ! (gdb-stopped . "\\*stopped,?\\(.*?\\)\n") ! (gdb-running . "\\*running,\\(.*?\n\\)") ! (gdb-thread-created . "=thread-created,\\(.*?\n\\)") ! (gdb-thread-selected . "=thread-selected,\\(.*?\\)\n") ! (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)") ! (gdb-ignored-notification . "=[-[:alpha:]]+,?\\(.*?\\)\n") (gdb-shell . "\\(\\(?:^.+\n\\)+\\)"))) (defun gud-gdbmi-marker-filter (string) "Filter GDB/MI output." --- 1904,1925 ---- (< (car a) (car b))) (defvar gdbmi-record-list ! '((gdb-gdb . "^(gdb) \n") ! (gdb-done . "^\\([0-9]*\\)\\^done,?\\(.*?\\)\n") ! (gdb-starting . "^\\([0-9]*\\)\\^running\n") ! (gdb-error . "^\\([0-9]*\\)\\^error,\\(.*?\\)\n") ! (gdb-console . "^~\\(\".*?\"\\)\n") ! (gdb-internals . "^&\\(\".*?\"\\)\n") ! (gdb-stopped . "^\\*stopped,?\\(.*?\\)\n") ! (gdb-running . "^\\*running,\\(.*?\n\\)") ! (gdb-thread-created . "^=thread-created,\\(.*?\n\\)") ! (gdb-thread-selected . "^=thread-selected,\\(.*?\\)\n") ! (gdb-thread-exited . "^=thread-exited,\\(.*?\n\\)") ! (gdb-ignored-notification . "^=[-[:alpha:]]+,?\\(.*?\\)\n") (gdb-shell . "\\(\\(?:^.+\n\\)+\\)"))) + (defvar gdb-accumulator nil) + (defun gud-gdbmi-marker-filter (string) "Filter GDB/MI output." *************** *** 1928,1954 **** (> (length gdb-debug-log) gdb-debug-log-max)) (setcdr (nthcdr (1- gdb-debug-log-max) gdb-debug-log) nil))) ! ;; Recall the left over gud-marker-acc from last time ! (setq gud-marker-acc (concat gud-marker-acc string)) ;; Start accumulating output for the GUD buffer (setq gdb-filter-output "") - (let (output-record-list) ! ;; Process all the complete markers in this chunk. ! (dolist (gdbmi-record gdbmi-record-list) ! (while (string-match (cdr gdbmi-record) gud-marker-acc) ! (push (list (match-beginning 0) ! (car gdbmi-record) ! (match-string 1 gud-marker-acc) ! (match-string 2 gud-marker-acc) ! (match-end 0)) ! output-record-list) ! (setq gud-marker-acc ! (concat (substring gud-marker-acc 0 (match-beginning 0)) ! ;; Pad with spaces to preserve position. ! (make-string (length (match-string 0 gud-marker-acc)) 32) ! (substring gud-marker-acc (match-end 0)))))) (setq output-record-list (sort output-record-list 'gdb-car<)) --- 1930,1960 ---- (> (length gdb-debug-log) gdb-debug-log-max)) (setcdr (nthcdr (1- gdb-debug-log-max) gdb-debug-log) nil))) ! ;; Recall the left over output from last time ! (unless gdb-accumulator ! (setq gdb-accumulator (get-buffer-create " *gdb output accumulator"))) ! ! (with-current-buffer gdb-accumulator ! (goto-char (point-max)) ! (insert string)) ;; Start accumulating output for the GUD buffer (setq gdb-filter-output "") ! ;; Process all the complete markers in this chunk. ! (let (output-record-list marker) ! (with-current-buffer gdb-accumulator ! (dolist (gdbmi-record gdbmi-record-list) ! (goto-char (point-min)) ! (while (re-search-forward (cdr gdbmi-record) nil t) ! (setq marker (make-marker)) ! (set-marker marker (match-beginning 0)) ! (push (list marker ! (car gdbmi-record) ! (match-string 1) ! (match-string 2)) ! output-record-list) ! (replace-match "\n")))) (setq output-record-list (sort output-record-list 'gdb-car<)) *************** *** 1969,1976 **** (setq gdb-output-sink 'user) ;; Remove padding. ! (string-match "^ *" gud-marker-acc) ! (setq gud-marker-acc (substring gud-marker-acc (match-end 0))) gdb-filter-output)) --- 1975,1984 ---- (setq gdb-output-sink 'user) ;; Remove padding. ! (with-current-buffer gdb-accumulator ! (goto-char (point-min)) ! (while (re-search-forward "^\n" nil t) ! (replace-match ""))) gdb-filter-output)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 11 04:30:12 2012 Received: (at 10580) by debbugs.gnu.org; 11 May 2012 08:30:12 +0000 Received: from localhost ([127.0.0.1]:47539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSlEp-0007TQ-Cd for submit@debbugs.gnu.org; Fri, 11 May 2012 04:30:11 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:53976) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSlEl-0007SX-Ud for 10580@debbugs.gnu.org; Fri, 11 May 2012 04:30:10 -0400 Received: by bkty8 with SMTP id y8so2000169bkt.3 for <10580@debbugs.gnu.org>; Fri, 11 May 2012 01:29:58 -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=IlL1COUCAPBbH4/Pn3cNmQj+SOdy/JZF7PzdMVCAWkM=; b=PwBRmeRFlkCtZ4Av3/LjA4rxch4hHmWc08zIb0OA1aSQrqugOKzbLkVJwOu7ev7/Dt PtYYk4E9LCE8RUtlqcsjTQH6VgMXnsRkLnrnNTKgnixBlkyY9vR8HQOh4Jm1pDTioEVS yWuC+VPPzUffindcej73upULtNEoj9BjmIblJYl0X8f0WeAPlkPlcHKQBDleExCYtEBj 7W6eCnXTE3jMYacTVJwcpr2Ma0G4LkXfDQGvOtiN3dQiBk+dPaks/QFc+4a0eVeXQngM mvxEF7B7dQaJRbaMZmTClCnEIwc6X8AWsc/EQYD5J4ei+9YE/kQdptYIswphzR2fVaam BQaQ== MIME-Version: 1.0 Received: by 10.204.154.80 with SMTP id n16mr4623276bkw.112.1336724997954; Fri, 11 May 2012 01:29:57 -0700 (PDT) Received: by 10.204.61.9 with HTTP; Fri, 11 May 2012 01:29:57 -0700 (PDT) In-Reply-To: <8762c3z0of.fsf@gnu.org> References: <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> Date: Fri, 11 May 2012 11:29:57 +0300 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=0015175ccf3eaa5cd004bfbe8a79 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , 10580@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --0015175ccf3eaa5cd004bfbe8a79 Content-Type: text/plain; charset=UTF-8 Here are the results. With patch1: ~155s With patch2: ~112s On the other hand, I have patched gdb, seehttp:// sourceware.org/bugzilla/show_bug.cgi?id=14081, to do uniq internally in gdb, and then it takes only about 10s. On Fri, May 11, 2012 at 9:33 AM, Chong Yidong wrote: > Dov Grobgeld writes: > > > Here are the tests when using the the latest cvs gdb that yields a gdb > > output file of about 800k. > > > > Without gdb-get-source-file-list override: ~139s > > With gdb-get-source-file-list override: ~125s > > > > Thus it is clear that most of the time is taken just reading the > > string into emacs. But doing find-file on the same file is almost > > instantaneous. > > Here's another little experiment. Could you apply the two attached > patches, individually, and see what difference each patch makes? > (Again, with gdb-create-source-file-list at its default of t, and > without any other patches to gdb-mi.el.) > > --0015175ccf3eaa5cd004bfbe8a79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are the res= ults.

With patch1: ~155s
With patch2: ~112s

On the other h= and, I have patched gdb, seehttp://sourceware.org/bugzilla/show_bug.cgi?id=3D14081<= /a>,=C2=A0 to do uniq internally in gdb, and then it takes only about 10s.<= br>
On Fri, May 11, 2012 at 9:33 AM, Chon= g Yidong <cyd@gnu.org> wrote:
Dov Grobgeld <dov.grobgeld@gmail.com> writes:

> Here are the tests when using the the latest cvs gdb that yields a gdb=
> output file of about 800k.
>
> Without gdb-get-source-file-list override: ~139s
> With gdb-get-source-file-list override: ~125s
>
> Thus it is clear that most of the time is taken just reading the
> string into emacs. But doing find-file on the same file is almost
> instantaneous.

Here's another little experiment. =C2=A0Could you apply the two a= ttached
patches, individually, and see what difference each patch makes?
(Again, with gdb-create-source-file-list at its default of t, and
without any other patches to gdb-mi.el.)


--0015175ccf3eaa5cd004bfbe8a79-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 11 05:50:04 2012 Received: (at 10580) by debbugs.gnu.org; 11 May 2012 09:50:04 +0000 Received: from localhost ([127.0.0.1]:48198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmU7-00014b-Mm for submit@debbugs.gnu.org; Fri, 11 May 2012 05:50:03 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:34123) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSmU4-000142-B1 for 10580@debbugs.gnu.org; Fri, 11 May 2012 05:50:01 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3U00F00R4LQL00@a-mtaout22.012.net.il> for 10580@debbugs.gnu.org; Fri, 11 May 2012 12:49:39 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3U00ELXRAQNRJ0@a-mtaout22.012.net.il>; Fri, 11 May 2012 12:49:39 +0300 (IDT) Date: Fri, 11 May 2012 12:47:53 +0300 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: X-012-Sender: halo1@inter.net.il To: Dov Grobgeld Message-id: <83vck3xd4m.fsf@gnu.org> References: <874nrsem67.fsf@gnu.org> <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.2 (-) > Date: Fri, 11 May 2012 11:29:57 +0300 > From: Dov Grobgeld > Cc: Eli Zaretskii , schwab@linux-m68k.org, 10580@debbugs.gnu.org > > With patch1: ~155s > With patch2: ~112s > > On the other hand, I have patched gdb, seehttp:// > sourceware.org/bugzilla/show_bug.cgi?id=14081, to do uniq internally in > gdb, and then it takes only about 10s. Which is much faster, but still way too slow. I think it's quite clear at this point that what takes time is reading the stuff from GDB, not parsing it. Chong, am I right? From debbugs-submit-bounces@debbugs.gnu.org Fri May 11 09:27:57 2012 Received: (at 10580) by debbugs.gnu.org; 11 May 2012 13:27:57 +0000 Received: from localhost ([127.0.0.1]:48421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpsy-00071d-9c for submit@debbugs.gnu.org; Fri, 11 May 2012 09:27:57 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:55090 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SSpst-00071T-1K for 10580@debbugs.gnu.org; Fri, 11 May 2012 09:27:52 -0400 Received: from cm162.gamma80.maxonline.com.sg ([202.156.80.162]:46469 helo=ulysses) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1SSpsj-0002NB-Qb; Fri, 11 May 2012 09:27:44 -0400 From: Chong Yidong To: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU References: <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> <83vck3xd4m.fsf@gnu.org> Date: Fri, 11 May 2012 21:27:36 +0800 In-Reply-To: <83vck3xd4m.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 11 May 2012 12:47:53 +0300") Message-ID: <874nrmzw3b.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.96 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -6.9 (------) X-Debbugs-Envelope-To: 10580 Cc: Dov Grobgeld , 10580@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Eli Zaretskii writes: > I think it's quite clear at this point that what takes time is reading > the stuff from GDB, not parsing it. Chong, am I right? That is what the evidence suggests, which indicates that we won't be able to fix it for 24.1. Maybe there is some problem in the adaptive read buffering code? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 05 15:39:27 2012 Received: (at 10580) by debbugs.gnu.org; 5 Nov 2012 20:39:27 +0000 Received: from localhost ([127.0.0.1]:51071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVTSB-0004Co-0L for submit@debbugs.gnu.org; Mon, 05 Nov 2012 15:39:27 -0500 Received: from mail-vb0-f44.google.com ([209.85.212.44]:42037) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVTS8-0004Cg-9j for 10580@debbugs.gnu.org; Mon, 05 Nov 2012 15:39:24 -0500 Received: by mail-vb0-f44.google.com with SMTP id fc26so8161392vbb.3 for <10580@debbugs.gnu.org>; Mon, 05 Nov 2012 12:36:16 -0800 (PST) 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=mkKTE7mK4gJyLW/sxNspZXZzOOLccrh3PJBWT7liY/Q=; b=vIp5FaL4VdlVFBU2X7JYCrcJzaJlWDciMStpWl24ytXroP+3WYpiqOqsFsqG1E9zde z1hl1ywlnUJdkKYKqtvda++rVClFgbBM7xXNGE0HsYY4TB9qqU3aOJv2+nXGPYR63FkU 8u013FRWXIN43D+xKU+vS4K0eCgJ4Qir5cXau/18FnYnHzIUFXwhK59ahUkaGPkaSFxj h4uaA0+AUWmHXcwNQ6u9RWZuldcfYlXzz+o2g9JYtrEhGIXgATPC3wP44xHd8k5/Nng2 RQk1klLJhRhVGVwyJ058TBz0OnrLZpudCsw/eFPYyaFeJ5a02023Pyg0nubkpb5KQOVu C++A== MIME-Version: 1.0 Received: by 10.52.33.130 with SMTP id r2mr9097460vdi.43.1352147776728; Mon, 05 Nov 2012 12:36:16 -0800 (PST) Received: by 10.58.18.161 with HTTP; Mon, 5 Nov 2012 12:36:16 -0800 (PST) In-Reply-To: <874nrmzw3b.fsf@gnu.org> References: <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> <83vck3xd4m.fsf@gnu.org> <874nrmzw3b.fsf@gnu.org> Date: Mon, 5 Nov 2012 22:36:16 +0200 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU From: Dov Grobgeld To: Chong Yidong Content-Type: multipart/alternative; boundary=20cf307c9cb2ea6e1004cdc56fee X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 10580 Cc: Eli Zaretskii , 10580@debbugs.gnu.org, Andreas Schwab X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --20cf307c9cb2ea6e1004cdc56fee Content-Type: text/plain; charset=UTF-8 Is there any chance of having this bug solved in the foreseeable future? This bug is the reason I am still sticking with emacs-23. As an alternative, is it possible to use the old gdb-mode (without -mi) in emacs-24? On Fri, May 11, 2012 at 4:27 PM, Chong Yidong wrote: > Eli Zaretskii writes: > > > I think it's quite clear at this point that what takes time is reading > > the stuff from GDB, not parsing it. Chong, am I right? > > That is what the evidence suggests, which indicates that we won't be > able to fix it for 24.1. Maybe there is some problem in the adaptive > read buffering code? > --20cf307c9cb2ea6e1004cdc56fee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any cha= nce of having this bug solved in the foreseeable future? This bug is the re= ason I am still sticking with emacs-23. As an alternative, is it pos= sible to use the old gdb-mode (without -mi) in emacs-24?



On = Fri, May 11, 2012 at 4:27 PM, Chong Yidong <cyd@gnu.org> wrote:
Eli Zaretskii <eliz@gn= u.org> writes:

> I think it's quite clear at this point that what takes time is rea= ding
> the stuff from GDB, not parsing it. =C2=A0Chong, am I right?

That is what the evidence suggests, which indicates that we won't= be
able to fix it for 24.1. =C2=A0Maybe there is some problem in the adaptive<= br> read buffering code?

--20cf307c9cb2ea6e1004cdc56fee-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 05 15:50:02 2012 Received: (at 10580) by debbugs.gnu.org; 5 Nov 2012 20:50:02 +0000 Received: from localhost ([127.0.0.1]:51081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVTcQ-0004Rt-9M for submit@debbugs.gnu.org; Mon, 05 Nov 2012 15:50:02 -0500 Received: from mtaout23.012.net.il ([80.179.55.175]:33693) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVTcO-0004RQ-Gg for 10580@debbugs.gnu.org; Mon, 05 Nov 2012 15:50:01 -0500 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MD10090085EV100@a-mtaout23.012.net.il> for 10580@debbugs.gnu.org; Mon, 05 Nov 2012 22:46:52 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MD1009S18E3L5C0@a-mtaout23.012.net.il>; Mon, 05 Nov 2012 22:46:52 +0200 (IST) Date: Mon, 05 Nov 2012 22:46:47 +0200 From: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU In-reply-to: X-012-Sender: halo1@inter.net.il To: Dov Grobgeld Message-id: <83r4o73hhk.fsf@gnu.org> References: <874nrswme9.fsf@gnu.org> <87zk9kv75l.fsf@gnu.org> <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> <83vck3xd4m.fsf@gnu.org> <874nrmzw3b.fsf@gnu.org> X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > Date: Mon, 5 Nov 2012 22:36:16 +0200 > From: Dov Grobgeld > Cc: Eli Zaretskii , Andreas Schwab , 10580@debbugs.gnu.org > > As an alternative, is it possible to use the old gdb-mode (without > -mi) in emacs-24? [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.179.55.175 listed in list.dnswl.org] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.2916] 0.5 HDRS_LCASE_1K Odd capitalization of message headers + long header X-Debbugs-Envelope-To: 10580 Cc: cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.2 (/) > Date: Mon, 5 Nov 2012 22:36:16 +0200 > From: Dov Grobgeld > Cc: Eli Zaretskii , Andreas Schwab , 10580@debbugs.gnu.org > > As an alternative, is it possible to use the old gdb-mode (without > -mi) in emacs-24? It was always possible: type "M-x gud-gdb RET". From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 05 18:54:51 2012 Received: (at 10580) by debbugs.gnu.org; 5 Nov 2012 23:54:51 +0000 Received: from localhost ([127.0.0.1]:51257 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVWVH-00017I-2i for submit@debbugs.gnu.org; Mon, 05 Nov 2012 18:54:51 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:65224) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TVWVG-00017D-5n for 10580@debbugs.gnu.org; Mon, 05 Nov 2012 18:54:50 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG6Zu0/O+LEi/2dsb2JhbABEsEiDSYEIghUBAQQBViMQCzQSFBgNJIgcBboJkEQDiEKacYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="205646551" Received: from 206-248-177-34.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([206.248.177.34]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Nov 2012 18:51:41 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9128CAE203; Mon, 5 Nov 2012 18:51:41 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100% CPU Message-ID: References: <87mx5j6pqs.fsf@gnu.org> <877gwm3ajn.fsf@gnu.org> <83txzq1s4y.fsf@gnu.org> <837gwl1ckx.fsf@gnu.org> <87pqacrunj.fsf@gnu.org> <8762c3z0of.fsf@gnu.org> <83vck3xd4m.fsf@gnu.org> <874nrmzw3b.fsf@gnu.org> <83r4o73hhk.fsf@gnu.org> Date: Mon, 05 Nov 2012 18:51:41 -0500 In-Reply-To: <83r4o73hhk.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Nov 2012 22:46:47 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.8 (/) X-Debbugs-Envelope-To: 10580 Cc: Dov Grobgeld , cyd@gnu.org, schwab@linux-m68k.org, 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.0 (/) >> As an alternative, is it possible to use the old gdb-mode (without >> -mi) in emacs-24? > It was always possible: type "M-x gud-gdb RET". IIUC this gives you the Emacs-22 version of M-x gdb, but not the Emacs-23 one (which used the gdb-ui.el code). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 13 23:22:23 2012 Received: (at 10580) by debbugs.gnu.org; 14 Dec 2012 04:22:24 +0000 Received: from localhost ([127.0.0.1]:41664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TjMn0-0002Zb-HM for submit@debbugs.gnu.org; Thu, 13 Dec 2012 23:22:23 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:60356) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TjMgm-0002LS-C2 for 10580@debbugs.gnu.org; Thu, 13 Dec 2012 23:16:13 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz11so2049665pad.3 for <10580@debbugs.gnu.org>; Thu, 13 Dec 2012 20:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ckv1Y80yiaDVGiLyHF9aeZg8O0SbIFG/SFpHGJxXc2M=; b=S4eyts0/DcGgFXi75YGSdtnvy8SknbYaW3NFHvhUWp2NudzAkC/xRnntveFqLq272w zy1R3xQqLM0GpgSxBYJlR6GtXlyFLB1u4fQOgq3uN7H29MRD73jow6aD66NCYL/N/7TR 4gTS8Rq7k2gAEup5Pk1hBTI70tsm3fkihkwGK2eri+bvAZ40gl6fZQVkMqn9SHHU4Z1q 0v82uDpq+vakEppJQv7xihsFJ+ktJiyaVrCILS3JgS1sVwWA4Dxa6bgHEKK0mXwkL0ZX BNP8EVjqfCcUWdK2BbszqiPOYwlXXK9t72Df3cOCL2tw7iYxnsxapskO+J4l1KDCFmAR NEDQ== MIME-Version: 1.0 Received: by 10.66.73.132 with SMTP id l4mr12452483pav.48.1355458499394; Thu, 13 Dec 2012 20:14:59 -0800 (PST) Received: by 10.68.50.36 with HTTP; Thu, 13 Dec 2012 20:14:59 -0800 (PST) Date: Thu, 13 Dec 2012 23:14:59 -0500 Message-ID: Subject: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100 From: Jean-Philippe Gravel To: 10580@debbugs.gnu.org Content-Type: multipart/alternative; boundary=f46d042f92525d3be404d0c84621 X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 10580 X-Mailman-Approved-At: Thu, 13 Dec 2012 23:22:18 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --f46d042f92525d3be404d0c84621 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi guys, I actually have a fix for this problem. I use Emacs to debug a software of colossal size. With Emacs 23, it used to be possible to start gdb within a minute. With Emacs 24, it takes more than a couple of hour. I never actually had the patience to wait for it to finish. As stated in previous posts, the command -file-list-exec-source-files is the one triggering the bottleneck. In my case, the reply is 5Mb long. It turns out that the problem IS the parsing of the data stream coming from GDB. The function gud-gdbmi-marker-filter is home to a colossal bottleneck. You=92ll find in there not only one, but 4 major algorithmic problems. The first thing that strikes the eye is the way it handles the fact that there are several types of GDB replies possible. Instead of parsing the data stream linearly, accepting the GDB messages in the order of arrival, it looks over the whole stream for the first type of message, then the second, then the next. Complexity: O(nm), where n is the size of the steam and m is the number of message types. Then, when finding a message matching the type we look for, it is removed from the stream by cloning the whole string, but padding the original location with spaces. Complexity: O(ni), where i is the number of messages. To go on with the analysis, consider the following: my tests indicate that gdbmi-marker-filter receives data by chunk of about 225 bytes. Since I receive 5Mb of data, gdbmi ingests about 22000 packets. For every chunk of data received, the incoming data is concatenated to a new string: O(nj), where j is the number of packets. Each time, the whole parsing described above is restarted: O(nmj) (!!!). Feed in a 5Mb data stream and you=92ll g= et a hung emacs! I fixed the above by writing a proper parser reading the data stream in O(n). With my test-case, the parse time goes down from =91too long to even tell=92, to about 3 seconds. Not only does it fix the startup problem, but it makes pretty much all other gud commands impressively faster. With emacs 23, it used to take almost a full second to do a single =93gud-next= =94 in my software. When enabling gud-tooltip-mode, it was becoming totally unusable. By removing the bottleneck in gud-gdbmi-marker-filter, the above become instantaneous. I just need to finalize a few things and I can send you a patch file. Cheers! --f46d042f92525d3be404d0c84621 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi guys,

=A0

I actually have a fix for this pro= blem.

=A0

I use Emacs to debug a software of= colossal size. =A0With Emacs 23, it used to be possible to start gdb within a minute. =A0With Emacs 24, it takes more than a couple of hour. =A0I never actually had the patience to wait for it to finish.

=A0

As stated in previous posts, the c= ommand -file-list-exec-source-files is the one triggering the bottleneck.=A0 In my case, the reply is 5Mb long.

=A0

It turns out that the problem IS t= he parsing of the data stream coming from GDB.=A0 The function gud-gdbmi-marker-filter is home to a colossal bottleneck.=A0 You=92ll find in there not only one, but 4 major algorithmic problems.

=A0

The first thing that strikes the e= ye is the way it handles the fact that there are several types of GDB replies possible. =A0Instead of parsing the = data stream linearly, accepting the GDB messages in the order of arrival, it looks over the whole stream fo= r the first type of message, then the second, then the next.=A0 Complexity: O= (nm), where n is the size of the steam and m is the number of message types.=A0 Then, when finding a message matching the type we look for, it is removed from the stream by cloning the whole string, but padding the origin= al location with spaces.=A0 Complexity: O(ni), where i is the number of messages.

=A0

To go on with the analysis, consid= er the following: my tests indicate that gdbmi-marker-filter receives data by chunk of about 225 bytes.=A0 Sinc= e I receive 5Mb of data, gdbmi ingests about 22000 packets.=A0 For every chunk of data received, the incoming data is concatenated to a new string: O(nj), where j= is the number of packets.=A0 Each time, the whole parsing described above is restarted: O(nmj) (!!!).=A0 Feed in a 5Mb data s= tream and you=92ll get a hung emacs!

=A0

I fixed the above by writing a pro= per parser reading the data stream in O(n).=A0 With my test-case, the parse time goes down from =91too long to even tell=92, to about 3 seconds.=A0 Not= only does it fix the startup problem, but it makes pretty much all other gud commands impressively faster.=A0 With em= acs 23, it used to take almost a full second to do a single =93gud-next=94 in my software.=A0 When enabling gud-t= ooltip-mode, it was becoming totally unusable.=A0 By removing the bottleneck in gud-gdbmi-marker-filter, the above become instantaneous.

=A0

I just need to finalize a few thin= gs and I can send you a patch file.

=A0

Cheers!

--f46d042f92525d3be404d0c84621-- From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 17 23:47:11 2012 Received: (at 10580) by debbugs.gnu.org; 18 Dec 2012 04:47:12 +0000 Received: from localhost ([127.0.0.1]:47979 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tkp5D-0008B0-8t for submit@debbugs.gnu.org; Mon, 17 Dec 2012 23:47:11 -0500 Received: from mail-vb0-f48.google.com ([209.85.212.48]:47812) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tkp5B-0008As-1c for 10580@debbugs.gnu.org; Mon, 17 Dec 2012 23:47:10 -0500 Received: by mail-vb0-f48.google.com with SMTP id fc21so278238vbb.7 for <10580@debbugs.gnu.org>; Mon, 17 Dec 2012 20:45:50 -0800 (PST) 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 :content-type; bh=p9ZqQ3WxzszqINNBszq04cgnLryWlR/wzI+4f1Xzzow=; b=t1CxxyGVOqNT0ekiCgcjvoPBW2OaFOHngcwzKoDOEPD2eQvmtiCJYgYlqPI0caXA8M klHbBPwpXhZZgXbIkY1zAr+R7Vy/W2D77D0tV0/pKV0NpfKSqEFbDl/TK+l5C+fw1H/j X67qJXVwD96qV4/urPu76K2MfmZraOoPUTL2V/1UIb+nZ2/ub2rGP5kazPe5H59Q6Chd Hfb5eO/Qj7eod04bLQq1RwAfFklQoUqYOHhBzEEK+wBu0cRrQLF/iQ0m9aJ+RVzZR+gw yAC2e97j8tMRARV3JEJ7iTCIAzrhk/TeYi/0WYNFQpbNb439kjHWcnTJVdFrAUEOU+c/ IIrw== MIME-Version: 1.0 Received: by 10.52.72.66 with SMTP id b2mr943303vdv.31.1355805950182; Mon, 17 Dec 2012 20:45:50 -0800 (PST) Received: by 10.58.65.104 with HTTP; Mon, 17 Dec 2012 20:45:49 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Dec 2012 23:45:49 -0500 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100 From: Jean-Philippe Gravel To: 10580@debbugs.gnu.org Content-Type: multipart/mixed; boundary=20cf307f34120b857404d1192c1b X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 10580 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --20cf307f34120b857404d1192c1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Here is my patch. As stated previously, I only re-wrote gud-gdbmi-marker-filter. This function now parses the GDB/MI records in the order of arrival. Only the signature of each record is read by the new parser. The actual content of the record (i.e. result strings) is still parsed by the original code (which I will refer to as the record handlers below). The new parser is based on the GDB/MI output BNF grammar available at: ftp://ftp.gnu.org/pub/old-gnu/Manuals/gdb/html_node/gdb_214.html#SEC221 Records that are too large to be received in one data chunk can be parsed progressively by the record handlers, if they support it. The global configuration alist =93gdbmi-bnf-result-state-configs=94 defines the mapping between record types and record handlers. This structure flags all the handlers as either progressive or atomic. Progressive handlers are invokes as soon as a partial data chunks are received. Atomic handlers on the other hand will not be invoked until the whole record is received. This design allowed me to progressively attack the optimization problem: the ^done / ^error messages being the biggest bottleneck (the reply to -file-list-exec-source-files), I started by only converting those to progressive parsing. If we find that other messages cause performance issue, we can always convert them to progressive parsing as well. That being said, while the handler for ^done and ^error (gdb-done-or-error) do receive the data progressively, it doesn=92t parse it on the fly. Instead, it accumulates the data chunks in a temporary buffer and parses its content only when the record is complete. This is sub-optimal, but my tests showed that optimizing this part would have only a minimal effect compared to fixing gud-gdbmi-marker-filter. I decided to keep this as a separate optimization task, to be done later. For performance reason, I tried to keep processing and data copy to a minimum. I therefore work in-place, directly in the gud-marker-acc string, instead of copying the string to a temporary buffer. The parser walks in the string using an offset stored in gdbmi-bnf-offset. By looking at the character at this offset, I can quickly detect the type of record we received, BEFORE trying to parse it with string-match. Note: I am a little confused about when the parser states should be (re)initialized. I would have expected the states to be initialized before the GDB process is started (before gud-common-init) because once the process starts, the marker-filter can be invoked at any time. Instead, I find that the gdb-mi variables are all initialized in gdb-init-1, which runs after the process is started. I added a new function gdbmi-bnf-init that is invoked from within gdb-init-1, but that doesn=92t seem right. Does anyone have an opinion on this? I certainly do think there is currently a problem because if the GDB/MI initialization is interrupted expectedly (for instance because of an error), it seems to restart in a very bad state the next time (I think that's true even before my fix)=85 Jean-Philippe --20cf307f34120b857404d1192c1b Content-Type: application/octet-stream; name="gdb-mi-optimization-1.patch" Content-Disposition: attachment; filename="gdb-mi-optimization-1.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_haujrsn81 PT09IG1vZGlmaWVkIGZpbGUgJ2xpc3AvcHJvZ21vZGVzL2dkYi1taS5lbCcKKioqIGxpc3AvcHJv Z21vZGVzL2dkYi1taS5lbAkyMDEyLTEwLTE4IDE5OjQ2OjE4ICswMDAwCi0tLSBsaXNwL3Byb2dt b2Rlcy9nZGItbWkuZWwJMjAxMi0xMi0xOCAwNDozMjoyNiArMDAwMAoqKioqKioqKioqKioqKiog QWxzbyBkaXNwbGF5IHRoZSBtYWluIHJvdXRpbmUgaW4gdGhlIGRpcwoqKiogNTA3LDUxMiAqKioq Ci0tLSA1MDcsNTE5IC0tLS0KICAgIDpncm91cCAnZ2RiCiAgICA6dmVyc2lvbiAiMjIuMSIpCiAg CisgKGRlZmN1c3RvbSBnZGJtaS1kZWJ1Zy1tb2RlIG5pbAorICAgIldoZW4gbm9uLW5pbCwgYWxs IHRoZSBtZXNzYWdlcyBzZW50IG9yIHJlY2VpdmVkIGZyb20gR0RCL01JIGFyZSBwcmludGVkIGlu CisgdGhlICpNZXNzYWdlcyogYnVmZmVyLiIKKyAgIDp0eXBlICdib29sZWFuCisgICA6Z3JvdXAg J2d1ZAorICAgOnZlcnNpb24gIjI0LjMiKQorIAogIChkZWZ1biBnZGItZm9yY2UtbW9kZS1saW5l LXVwZGF0ZSAoc3RhdHVzKQogICAgKGxldCAoKGJ1ZmZlciBndWQtY29taW50LWJ1ZmZlcikpCiAg ICAgIChpZiAoYW5kIGJ1ZmZlciAoYnVmZmVyLW5hbWUgYnVmZmVyKSkKKioqKioqKioqKioqKioq IGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoaXMgbW9kZS4KKioqIDg0Niw4NTEgKioqKgotLS0g ODUzLDg2MCAtLS0tCiAgICAgICAgICBnZGItcmVnaXN0ZXItbmFtZXMgJygpCiAgICAgICAgICBn ZGItbm9uLXN0b3AgZ2RiLW5vbi1zdG9wLXNldHRpbmcpCiAgICA7OworICAgKGdkYm1pLWJuZi1p bml0KQorICAgOzsKICAgIChzZXRxIGdkYi1idWZmZXItdHlwZSAnZ2RibWkpCiAgICA7OwogICAg KGdkYi1mb3JjZS1tb2RlLWxpbmUtdXBkYXRlCioqKioqKioqKioqKioqKiBjb21wbGV0ZS4iCioq KiAxNzM5LDE3NDQgKioqKgotLS0gMTc0OCwxNzU0IC0tLS0KICAgIChzZXRxIGdkYi10b2tlbi1u dW1iZXIgKDErIGdkYi10b2tlbi1udW1iZXIpKQogICAgKHNldHEgY29tbWFuZCAoY29uY2F0IChu dW1iZXItdG8tc3RyaW5nIGdkYi10b2tlbi1udW1iZXIpIGNvbW1hbmQpKQogICAgKHB1c2ggKGNv bnMgZ2RiLXRva2VuLW51bWJlciBoYW5kbGVyLWZ1bmN0aW9uKSBnZGItaGFuZGxlci1hbGlzdCkK KyAgIChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJnZGItaW5wdXQ6ICVzIiBjb21tYW5k KSkKICAgIChwcm9jZXNzLXNlbmQtc3RyaW5nIChnZXQtYnVmZmVyLXByb2Nlc3MgZ3VkLWNvbWlu dC1idWZmZXIpCiAgCQkgICAgICAgKGNvbmNhdCBjb21tYW5kICJcbiIpKSkKICAKKioqKioqKioq KioqKioqIGlzIHJ1bm5pbmcuIgoqKiogMTg3NCwxODk2ICoqKioKICAgICAgICAoc2V0LXdpbmRv dy1idWZmZXIgc291cmNlLXdpbmRvdyBidWZmZXIpKQogICAgICBzb3VyY2Utd2luZG93KSkKICAK LSAoZGVmdW4gZ2RiLWNhcjwgKGEgYikKLSAgICg8IChjYXIgYSkgKGNhciBiKSkpCiAgCiEgKGRl ZnZhciBnZGJtaS1yZWNvcmQtbGlzdAohICAgJygoZ2RiLWdkYiAuICIoZ2RiKSBcbiIpCiEgICAg IChnZGItZG9uZSAuICJcXChbMC05XSpcXClcXF5kb25lLD9cXCguKj9cXClcbiIpCiEgICAgIChn ZGItc3RhcnRpbmcgLiAiXFwoWzAtOV0qXFwpXFxecnVubmluZ1xuIikKISAgICAgKGdkYi1lcnJv ciAuICJcXChbMC05XSpcXClcXF5lcnJvcixcXCguKj9cXClcbiIpCiEgICAgIChnZGItY29uc29s ZSAuICJ+XFwoXCIuKj9cIlxcKVxuIikKISAgICAgKGdkYi1pbnRlcm5hbHMgLiAiJlxcKFwiLio/ XCJcXClcbiIpCiEgICAgIChnZGItc3RvcHBlZCAuICJcXCpzdG9wcGVkLD9cXCguKj9cXClcbiIp CiEgICAgIChnZGItcnVubmluZyAuICJcXCpydW5uaW5nLFxcKC4qP1xuXFwpIikKISAgICAgKGdk Yi10aHJlYWQtY3JlYXRlZCAuICI9dGhyZWFkLWNyZWF0ZWQsXFwoLio/XG5cXCkiKQohICAgICAo Z2RiLXRocmVhZC1zZWxlY3RlZCAuICI9dGhyZWFkLXNlbGVjdGVkLFxcKC4qP1xcKVxuIikKISAg ICAgKGdkYi10aHJlYWQtZXhpdGVkIC4gIj10aHJlYWQtZXhpdGVkLFxcKC4qP1xuXFwpIikKISAg ICAgKGdkYi1pZ25vcmVkLW5vdGlmaWNhdGlvbiAuICI9Wy1bOmFscGhhOl1dKyw/XFwoLio/XFwp XG4iKQohICAgICAoZ2RiLXNoZWxsIC4gIlxcKFxcKD86Xi4rXG5cXCkrXFwpIikpKQogIAogIChk ZWZ1biBndWQtZ2RibWktbWFya2VyLWZpbHRlciAoc3RyaW5nKQogICAgIkZpbHRlciBHREIvTUkg b3V0cHV0LiIKLS0tIDE4ODQsMjIwNSAtLS0tCiAgICAgICAgKHNldC13aW5kb3ctYnVmZmVyIHNv dXJjZS13aW5kb3cgYnVmZmVyKSkKICAgICAgc291cmNlLXdpbmRvdykpCiAgCiAgCiEgKGRlZnVu IGdkYm1pLXN0YXJ0LXdpdGggKHN0ciBvZmZzZXQgbWF0Y2gpCiEgICAiUmV0dXJucyBub24tbmls IGlmIHN0cmluZyBTVFIgc3RhcnRzIHdpdGggTUFUQ0gsIGVsc2UgcmV0dXJucyBuaWwuCiEgT0ZG U0VUIGlzIHRoZSBwb3NpdGlvbiBpbiBTVFIgYXQgd2hpY2ggdGhlIGNvbXBhcmlzb24gdGFrZXMg cGxhY2UuIgohICAgKGxldCAoKG1hdGNoLWxlbmd0aCAobGVuZ3RoIG1hdGNoKSkKISAJKHN0ci1s ZW5ndGggKC0gKGxlbmd0aCBzdHIpIG9mZnNldCkpKQohICAgICAod2hlbiAoPj0gc3RyLWxlbmd0 aCBtYXRjaC1sZW5ndGgpCiEgICAgICAgKHN0cmluZy1lcXVhbCBtYXRjaCAoc3Vic3RyaW5nIHN0 ciBvZmZzZXQgKCsgb2Zmc2V0IG1hdGNoLWxlbmd0aCkpKSkpKQohIAohIChkZWZ1biBnZGJtaS1z YW1lLXN0YXJ0IChzdHIgb2Zmc2V0IG1hdGNoKQohICAgIlJldHVybnMgbm9uLW5pbCBpZiBTVFIg YW5kIE1BVENIIGFyZSBlcXVhbCB1cCB0byB0aGUgZW5kIG9mIGVpdGhlciBzdHJpbmdzLCBlbHNl IHJldHVybnMgbmlsLgohIE9GRlNFVCBpcyB0aGUgcG9zaXRpb24gaW4gU1RSIGF0IHdoaWNoIHRo ZSBjb21wYXJpc29uIHRha2VzIHBsYWNlLiIKISAgIChsZXQqICgoc3RyLWxlbmd0aCAoLSAobGVu Z3RoIHN0cikgb2Zmc2V0KSkKISAJIChtYXRjaC1sZW5ndGggKGxlbmd0aCBtYXRjaCkpCiEgCSAo Y29tcGFyZS1sZW5ndGggKG1pbiBzdHItbGVuZ3RoIG1hdGNoLWxlbmd0aCkpKQohICAgICAod2hl biAoPiBjb21wYXJlLWxlbmd0aCAwKQohICAgICAgIChzdHJpbmctZXF1YWwgKHN1YnN0cmluZyBz dHIgb2Zmc2V0ICgrIG9mZnNldCBjb21wYXJlLWxlbmd0aCkpCiEgCQkgICAgKHN1YnN0cmluZyBt YXRjaCAwIGNvbXBhcmUtbGVuZ3RoKSkpKSkKISAKISAoZGVmdW4gZ2RibWktaXMtbnVtYmVyIChj aGFyYWN0ZXIpCiEgIlJldHVybnMgbm9uLW5pbCBpZiBDSEFSQUNURVIgaXMgYSBudW1lcmljYWwg Y2hhcmFjdGVyIGJldHdlZW4gMCBhbmQgOSwKISBlbHNlIHJldHVybnMgbmlsLiIKISAgIChhbmQg KD49IGNoYXJhY3RlciA/MCkKISAgICAgICAgKDw9IGNoYXJhY3RlciA/OSkpKQohIAohIAohIChk ZWZ2YXIgZ2RibWktYm5mLXN0YXRlICdnZGJtaS1ibmYtb3V0cHV0CiEgICAiQ3VycmVudCBHREIv TUkgb3V0cHV0IHBhcnNlciBzdGF0ZS4gIFRoZSBwYXJzZXIgaXMgcGxhY2VkIGluIGEKISBkaWZm ZXJlbnQgc3RhdGUgd2hlbiBhbiBpbmNvbXBsZXRlIGRhdGEgc3RlYW0gaXMgcmVjZWl2ZWQgZnJv bSBHREIuCiEgVGhpcyB2YXJpYWJsZSB3aWxsIHByZXNlcnZlIHRoZSBzdGF0ZSByZXF1aXJlZCB0 byByZXN1bWUgdGhlIHBhcnNpbmcKISB3aGVuIG1vcmUgZGF0YSBhcnJpdmVzLiIpCiEgKG1ha2Ut dmFyaWFibGUtYnVmZmVyLWxvY2FsICdnZGJtaS1ibmYtc3RhdGUpCiEgCiEgKGRlZnZhciBnZGJt aS1ibmYtb2Zmc2V0IDAKISAgICJPZmZzZXQgaW4gZ3VkLW1hcmtlci1hY2MgYXQgd2hpY2ggdGhl IHBhcnNlciBpcyByZWFkaW5nLgohIFRoaXMgb2Zmc2V0IGlzIHVzZWQgdG8gYmUgYWJsZSB0byBw YXJzZSB0aGUgR0RCL01JIG1lc3NhZ2UKISBpbi1wbGFjZSwgd2l0aG91dCB0aGUgbmVlZCBvZiBj b3B5aW5nIHRoZSBzdHJpbmcgaW4gYSB0ZW1wb3JhcnkgYnVmZmVyCiEgb3IgZGlzY2FyZGluZyBw YXJzZWQgdG9rZW5zIGJ5IHN1YnN0cmluZ2luZyB0aGUgbWVzc2FnZS4iKQohIChtYWtlLXZhcmlh YmxlLWJ1ZmZlci1sb2NhbCAnZ2RibWktYm5mLW9mZnNldCkKISAKISAoZGVmdW4gZ2RibWktYm5m LWluaXQgKCkKISAgICJJbml0aWFsaXplcyB0aGUgR0RCL01JIG1lc3NhZ2UgcGFyc2VyIgohICAg KHNldHEgZ2RibWktYm5mLXN0YXRlICdnZGJtaS1ibmYtb3V0cHV0KQohICAgKHNldHEgZ2RibWkt Ym5mLW9mZnNldCAwKQohICAgKHNldHEgZ3VkLW1hcmtlci1hY2MgIiIpKQohIAohIAohIChkZWZ1 biBnZGJtaS1ibmYtb3V0cHV0ICgpCiEgICAiSW1wbGVtZW50YXRpb24gb2YgdGhlIGZvbGxvd2lu ZyBHREIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZToKISAKISAgIG91dHB1dCA9PT4KISAgICAgICAg KCBvdXQtb2YtYmFuZC1yZWNvcmQgKSogWyByZXN1bHQtcmVjb3JkIF0gZ2RiLXByb21wdCIKISAK ISAgICAgKGdkYm1pLWJuZi1za2lwLXVucmVjb2duaXplZCkKISAgICAgKHdoaWxlIChnZGJtaS1i bmYtb3V0LW9mLWJhbmQtcmVjb3JkKSkKISAgICAgKGdkYm1pLWJuZi1yZXN1bHQtcmVjb3JkKQoh ICAgICAoZ2RibWktYm5mLWdkYi1wcm9tcHQpKQohIAohIAohIChkZWZ1biBnZGJtaS1ibmYtc2tp cC11bnJlY29nbml6ZWQgKCkKISAiVXNlZCBhcyBhIHByb3RlY3Rpb24gbWVjaGFuaXNtIGluIGNh c2Ugc29tZXRoaW5nIGdvZXMgd3Jvbmcgd2hlbiBwYXJzaW5nCiEgYSBHREIvTUkgcmVwbHkgbWVz c2FnZS4gIFRoaXMgZnVuY3Rpb24gd2lsbCBza2lwIGNoYXJhY3RlcnMgdW50aWwgaXMgZW5jb3Vu dGVycwohIHRoZSBiZWdpbm5pbmcgb2YgYSB2YWxpZCByZWNvcmQuIgohICAgKGxldCAoKGFjYy1s ZW5ndGggKGxlbmd0aCBndWQtbWFya2VyLWFjYykpCiEgCShwcmVmaXgtb2Zmc2V0IGdkYm1pLWJu Zi1vZmZzZXQpCiEgCShwcm9tcHQgIihnZGIpIFxuIikpCiEgCiEgICAgICh3aGlsZSAoYW5kICg8 IHByZWZpeC1vZmZzZXQgYWNjLWxlbmd0aCkKISAgICAgICAgICAgICAgICAgKGdkYm1pLWlzLW51 bWJlciAoYXJlZiBndWQtbWFya2VyLWFjYyBwcmVmaXgtb2Zmc2V0KSkpCiEgICAgICAgKHNldHEg cHJlZml4LW9mZnNldCAoMSsgcHJlZml4LW9mZnNldCkpKQohIAohICAgICAoaWYgKGFuZCAoPCBw cmVmaXgtb2Zmc2V0IGFjYy1sZW5ndGgpCiEgICAgICAgICAgICAgIChub3QgKG1lbWJlciAoYXJl ZiBndWQtbWFya2VyLWFjYyBwcmVmaXgtb2Zmc2V0KSAnKD9eID8qID8rID89ID9+ID9AID8mKSkp CiEgICAgICAgICAgICAgIChub3QgKGdkYm1pLXNhbWUtc3RhcnQgZ3VkLW1hcmtlci1hY2MgZ2Ri bWktYm5mLW9mZnNldCBwcm9tcHQpKQohICAgICAgICAgICAgICAoc3RyaW5nLW1hdGNoICJcXChb Xl4qKz1+QCZdK1xcKSIgZ3VkLW1hcmtlci1hY2MgZ2RibWktYm5mLW9mZnNldCkpCiEgICAgICAg ICAobGV0ICgodW5yZWNvZ25pemVkLXN0ciAobWF0Y2gtc3RyaW5nIDAgZ3VkLW1hcmtlci1hY2Mp KSkKISAgICAgICAgICAgKHNldHEgZ2RibWktYm5mLW9mZnNldCAobWF0Y2gtZW5kIDApKQohIAkg IChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJnZGJtaS1ibmYtc2tpcC11bnJlY29nbml6 ZWQ6ICVzIiB1bnJlY29nbml6ZWQtc3RyKSkKISAgICAgICAgICAgKGdkYi1zaGVsbCB1bnJlY29n bml6ZWQtc3RyKQohIAkgIHQpKSkpCiEgCiEgCiEgKGRlZnVuIGdkYm1pLWJuZi1nZGItcHJvbXB0 ICgpCiEgICAiSW1wbGVtZW50YXRpb24gb2YgdGhlIGZvbGxvd2luZyBHREIvTUkgb3V0cHV0IGdy YW1tYXIgcnVsZToKISAgIGdkYi1wcm9tcHQgPT0+CiEgICAgICAgICcoZ2RiKScgbmwKISAKISAg IG5sID09PgohICAgICAgICBDUiB8IENSLUxGIgohIAohICAgKGxldCAoKHByb21wdCAiKGdkYikg XG4iKSkKISAgICAgKHdoZW4gKGdkYm1pLXN0YXJ0LXdpdGggZ3VkLW1hcmtlci1hY2MgZ2RibWkt Ym5mLW9mZnNldCBwcm9tcHQpCiEgICAgICAgKGlmIGdkYm1pLWRlYnVnLW1vZGUgKG1lc3NhZ2Ug ImdkYm1pLWJuZi1nZGItcHJvbXB0OiAlcyIgcHJvbXB0KSkKISAgICAgICAoZ2RiLWdkYiBwcm9t cHQpCiEgICAgICAgKHNldHEgZ2RibWktYm5mLW9mZnNldCAoKyBnZGJtaS1ibmYtb2Zmc2V0IChs ZW5ndGggcHJvbXB0KSkpCiEgCiEgICAgICAgOzsgUmV0dXJucyBub24tbmlsIHRvIHRlbGwgZ3Vk LWdkYm1pLW1hcmtlci1maWx0ZXIgd2UndmUgcmVhY2hlZAohICAgICAgIDs7IHRoZSBlbmQgb2Yg YSBHREIgcmVwbHkgbWVzc2FnZS4KISAgICAgICB0KSkpCiEgCiEgCiEgKGRlZnVuIGdkYm1pLWJu Zi1yZXN1bHQtcmVjb3JkICgpCiEgICAiSW1wbGVtZW50YXRpb24gb2YgdGhlIGZvbGxvd2luZyBH REIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZToKISAKISAgIHJlc3VsdC1yZWNvcmQgPT0+CiEgICAg ICAgIFsgdG9rZW4gXSAnXicgcmVzdWx0LWNsYXNzICggJywnIHJlc3VsdCApKiBubAohIAohICAg dG9rZW4gPT0+CiEgICAgICAgIGFueSBzZXF1ZW5jZSBvZiBkaWdpdHMuIgohIAohICAgKGdkYm1p LWJuZi1yZXN1bHQtYW5kLWFzeW5jLXJlY29yZC1pbXBsKSkKISAKISAKISAoZGVmdW4gZ2RibWkt Ym5mLW91dC1vZi1iYW5kLXJlY29yZCAoKQohICAgIkltcGxlbWVudGF0aW9uIG9mIHRoZSBmb2xs b3dpbmcgR0RCL01JIG91dHB1dCBncmFtbWFyIHJ1bGU6CiEgCiEgICBvdXQtb2YtYmFuZC1yZWNv cmQgPT0+CiEgICAgICAgIGFzeW5jLXJlY29yZCB8IHN0cmVhbS1yZWNvcmQiCiEgCiEgICAob3Ig KGdkYm1pLWJuZi1hc3luYy1yZWNvcmQpCiEgICAgICAgKGdkYm1pLWJuZi1zdHJlYW0tcmVjb3Jk KSkpCiEgCiEgCiEgKGRlZnVuIGdkYm1pLWJuZi1hc3luYy1yZWNvcmQgKCkKISAgICJJbXBsZW1l bnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nIEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlczoKISAK ISAgIGFzeW5jLXJlY29yZCA9PT4KISAgICAgICAgZXhlYy1hc3luYy1vdXRwdXQgfCBzdGF0dXMt YXN5bmMtb3V0cHV0IHwgbm90aWZ5LWFzeW5jLW91dHB1dAohIAohICAgZXhlYy1hc3luYy1vdXRw dXQgPT0+CiEgICAgICAgIFsgdG9rZW4gXSAnKicgYXN5bmMtb3V0cHV0CiEgCiEgICBzdGF0dXMt YXN5bmMtb3V0cHV0ID09PgohICAgICAgICBbIHRva2VuIF0gJysnIGFzeW5jLW91dHB1dAohIAoh ICAgbm90aWZ5LWFzeW5jLW91dHB1dCA9PT4KISAgICAgICAgWyB0b2tlbiBdICc9JyBhc3luYy1v dXRwdXQKISAKISAgIGFzeW5jLW91dHB1dCA9PT4KISAgICAgICAgYXN5bmMtY2xhc3MgKCAnLCcg cmVzdWx0ICkqIG5sIgohIAohICAgKGdkYm1pLWJuZi1yZXN1bHQtYW5kLWFzeW5jLXJlY29yZC1p bXBsKSkKISAKISAKISAoZGVmdW4gZ2RibWktYm5mLXN0cmVhbS1yZWNvcmQgKCkKISAgICJJbXBs ZW1lbnQgdGhlIGZvbGxvd2luZyBHREIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZToKISAgIHN0cmVh bS1yZWNvcmQgPT0+CiEgICAgICAgIGNvbnNvbGUtc3RyZWFtLW91dHB1dCB8IHRhcmdldC1zdHJl YW0tb3V0cHV0IHwgbG9nLXN0cmVhbS1vdXRwdXQKISAKISAgIGNvbnNvbGUtc3RyZWFtLW91dHB1 dCA9PT4KISAgICAgICAgJ34nIGMtc3RyaW5nCiEgCiEgICB0YXJnZXQtc3RyZWFtLW91dHB1dCA9 PT4KISAgICAgICAgJ0AnIGMtc3RyaW5nCiEgCiEgICBsb2ctc3RyZWFtLW91dHB1dCA9PT4KISAg ICAgICAgJyYnIGMtc3RyaW5nIgohICAgKHdoZW4gKDwgZ2RibWktYm5mLW9mZnNldCAobGVuZ3Ro IGd1ZC1tYXJrZXItYWNjKSkKISAgICAgKGlmIChhbmQgKG1lbWJlciAoYXJlZiBndWQtbWFya2Vy LWFjYyBnZGJtaS1ibmYtb2Zmc2V0KSAnKD9+ID9AID8mKSkKISAgICAgICAgICAgICAgKHN0cmlu Zy1tYXRjaCAiXFwoW35AJl1cXClcXChcIi4qP1wiXFwpXG4iIGd1ZC1tYXJrZXItYWNjIGdkYm1p LWJuZi1vZmZzZXQpKQohICAgICAgICAgKGxldCAoKHByZWZpeCAobWF0Y2gtc3RyaW5nIDEgZ3Vk LW1hcmtlci1hY2MpKQohICAgICAgICAgICAgICAgKGMtc3RyaW5nIChtYXRjaC1zdHJpbmcgMiBn dWQtbWFya2VyLWFjYykpKQohIAohICAgICAgICAgICAoc2V0cSBnZGJtaS1ibmYtb2Zmc2V0ICht YXRjaC1lbmQgMCkpCiEgICAgICAgICAgIChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJn ZGJtaS1ibmYtc3RyZWFtLXJlY29yZDogJXMiIChtYXRjaC1zdHJpbmcgMCBndWQtbWFya2VyLWFj YykpKQohIAohICAgICAgICAgICAoY29uZCAoKHN0cmluZy1lcXVhbCBwcmVmaXggIn4iKQohICAg ICAgICAgICAgICAgICAgKGdkYm1pLWJuZi1jb25zb2xlLXN0cmVhbS1vdXRwdXQgYy1zdHJpbmcp KQohICAgICAgICAgICAgICAgICAoKHN0cmluZy1lcXVhbCBwcmVmaXggIkAiKQohICAgICAgICAg ICAgICAgICAgKGdkYm1pLWJuZi10YXJnZXQtc3RyZWFtLW91dHB1dCBjLXN0cmluZykpCiEgICAg ICAgICAgICAgICAgICgoc3RyaW5nLWVxdWFsIHByZWZpeCAiJiIpCiEgICAgICAgICAgICAgICAg ICAoZ2RibWktYm5mLWxvZy1zdHJlYW0tb3V0cHV0IGMtc3RyaW5nKSkpCiEgCSAgdCkpKSkKISAK ISAoZGVmdW4gZ2RibWktYm5mLWNvbnNvbGUtc3RyZWFtLW91dHB1dCAoYy1zdHJpbmcpCiEgICAi SGFuZGxlciBmb3IgdGhlIGNvbnNvbGUtc3RyZWFtLW91dHB1dCBHREIvTUkgb3V0cHV0IGdyYW1t YXIgcnVsZSIKISAgIChnZGItY29uc29sZSBjLXN0cmluZykpCiEgCiEgKGRlZnVuIGdkYm1pLWJu Zi10YXJnZXQtc3RyZWFtLW91dHB1dCAoYy1zdHJpbmcpCiEgICAiSGFuZGxlciBmb3IgdGhlIHRh cmdldC1zdHJlYW0tb3V0cHV0IEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlIgohICAgOzsgTm90 IGN1cnJlbnRseSB1c2VkLgohICAgKQohIAohIChkZWZ1biBnZGJtaS1ibmYtbG9nLXN0cmVhbS1v dXRwdXQgKGMtc3RyaW5nKQohICAgIkhhbmRsZXIgZm9yIHRoZSBsb2ctc3RyZWFtLW91dHB1dCBH REIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZSIKISAgIDs7IFN1cHByZXNzICJObyByZWdpc3RlcnMu IiAgR0RCIDYuOCBhbmQgZWFybGllcgohICAgOzsgZHVwbGljYXRlcyBNSSBlcnJvciBtZXNzYWdl IG9uIGludGVybmFsIHN0cmVhbS4KISAgIDs7IERvbid0IHByaW50IHRvIEdVRCBidWZmZXIuCiEg ICAoaWYgKG5vdCAoc3RyaW5nLWVxdWFsIChyZWFkIGMtc3RyaW5nKSAiTm8gcmVnaXN0ZXJzLlxu IikpCiEgICAgICAgKGdkYi1pbnRlcm5hbHMgYy1zdHJpbmcpKSkKISAKISAKISAoZGVmY29uc3Qg Z2RibWktYm5mLXJlc3VsdC1zdGF0ZS1jb25maWdzCiEgICAnKCgiXiIgLiAoKCJkb25lIiAuIChn ZGItZG9uZSAuIHByb2dyZXNzaXZlKSkKISAgICAgICAgICAgICAoImVycm9yIiAuIChnZGItZXJy b3IgLiBwcm9ncmVzc2l2ZSkpCiEgICAgICAgICAgICAgKCJydW5uaW5nIiAuIChnZGItc3RhcnRp bmcgLiBhdG9taWMpKSkpCiEgICAgICgiKiIgLiAoKCJzdG9wcGVkIiAuIChnZGItc3RvcHBlZCAu IGF0b21pYykpCiEgICAgICAgICAgICAgKCJydW5uaW5nIiAuIChnZGItcnVubmluZyAuIGF0b21p YykpKSkKISAgICAgKCIrIiAuICgpKQohICAgICAoIj0iIC4gKCgidGhyZWFkLWNyZWF0ZWQiIC4g KGdkYi10aHJlYWQtY3JlYXRlZCAuIGF0b21pYykpCiEgICAgICAgICAgICAgKCJ0aHJlYWQtc2Vs ZWN0ZWQiIC4gKGdkYi10aHJlYWQtc2VsZWN0ZWQgLiBhdG9taWMpKQohICAgICAgICAgICAgICgi dGhyZWFkLWV4aXN0ZWQiIC4gKGdkYi1pZ25vcmVkLW5vdGlmaWNhdGlvbiAuIGF0b21pYykpCiEg ICAgICAgICAgICAgKCdkZWZhdWx0IC4gKGdkYi1pZ25vcmVkLW5vdGlmaWNhdGlvbiAuIGF0b21p YykpKSkpCiEgICAiVHdvIGRpbWVuc2lvbmFsIGFsaXN0LCBtYXBwaW5nIHRoZSB0eXBlIGFuZCBj bGFzcyBvZiBtZXNzYWdlIHRvIGEgaGFuZGxlciBmdW5jdGlvbi4KISBIYW5kbGVyIGZ1bmN0aW9u cyBhcmUgYWxsIGZsYWdnZWQgYXMgZWl0aGVyICdwcm9ncmVzc2l2ZScgb3IgJ2F0b21pYycuICAn cHJvZ3Jlc3NpdmUnCiEgaGFuZGxlcnMgYXJlIGNhcGFibGUgb2YgcGFyc2luZyBpbmNvbXBsZXRl IG1lc3NhZ2VzLiAgVGhleSBjYW4gYmUgY2FsbGVkIHNldmVyYWwgdGltZQohIHdpdGggbmV3IGRh dGEgY2h1bmsgYXMgdGhleSBhcnJpdmUgZnJvbSBHREIuICAncHJvZ3Jlc3NpdmUnIGhhbmRsZXIg bXVzdCBoYXZlIGFuIGV4dHJhCiEgYXJndW1lbnQgdGhhdCBpcyBzZXQgdG8gYSBub24tbmlsIHZh bHVlIHdoZW4gdGhlIG1lc3NhZ2UgaXMgY29tcGxldGUuCiEgCiEgSW1wbGVtZW50IHRoZSBmb2xs b3dpbmcgR0RCL01JIG91dHB1dCBncmFtbWFyIHJ1bGU6CiEgICByZXN1bHQtY2xhc3MgPT0+CiEg ICAgICAgICdkb25lJyB8ICdydW5uaW5nJyB8ICdjb25uZWN0ZWQnIHwgJ2Vycm9yJyB8ICdleGl0 JwohIAohICAgYXN5bmMtY2xhc3MgPT0+CiEgICAgICAgICdzdG9wcGVkJyB8IG90aGVycyAod2hl cmUgb3RoZXJzIHdpbGwgYmUgYWRkZWQgZGVwZW5kaW5nIG9uIHRoZSBuZWVkcy0tdGhpcyBpcyBz dGlsbCBpbiBkZXZlbG9wbWVudCkuIikKISAKISAoZGVmdW4gZ2RibWktYm5mLXJlc3VsdC1hbmQt YXN5bmMtcmVjb3JkLWltcGwgKCkKISAgICJDb21tb24gaW1wbGVtZW50YXRpb24gb2YgdGhlIHJl c3VsdC1yZWNvcmQgYW5kIGFzeW5jLXJlY29yZCBydWxlLiAgQm90aCBydWxlIHNoYXJlCiEgdGhl IHNhbWUgc3ludGF4LiAgVGhvc2UgcmVjb3JkcyBtYXkgYmUgdmVyeSBsYXJnZSBpbiBzaXplLiAg Rm9yIHRoYXQgcmVhc29uLCB0aGUgJ3Jlc3VsdCcKISBwYXJ0IG9mIHRoZSAgcmVjb3JkIGlzIHBh cnNlZCBieSBnZGJtaS1ibmYtaW5jb21wbGV0ZS1yZWNvcmQtcmVzdWx0LCB3aGljaCB3aWxsIGtl ZXAKISByZWNlaXZpbmcgY2hhcmFjdGVycyBhcyB0aGV5IGFycml2ZSBmcm9tIEdEQiB1bnRpbCB0 aGUgcmVjb3JkIGlzIGNvbXBsZXRlLiIKISAgIChsZXQgKChhY2MtbGVuZ3RoIChsZW5ndGggZ3Vk LW1hcmtlci1hY2MpKQohIAkocHJlZml4LW9mZnNldCBnZGJtaS1ibmYtb2Zmc2V0KSkKISAKISAg ICAgKHdoaWxlIChhbmQgKDwgcHJlZml4LW9mZnNldCBhY2MtbGVuZ3RoKQohICAgICAgICAgICAg ICAgICAoZ2RibWktaXMtbnVtYmVyIChhcmVmIGd1ZC1tYXJrZXItYWNjIHByZWZpeC1vZmZzZXQp KSkKISAgICAgICAoc2V0cSBwcmVmaXgtb2Zmc2V0ICgxKyBwcmVmaXgtb2Zmc2V0KSkpCiEgCiEg ICAgIChpZiAoYW5kICg8IHByZWZpeC1vZmZzZXQgYWNjLWxlbmd0aCkKISAgICAgICAgICAgICAg KG1lbWJlciAoYXJlZiBndWQtbWFya2VyLWFjYyBwcmVmaXgtb2Zmc2V0KSAnKD8qID8rID89ID9e KSkKISAgICAgICAgICAgICAgKHN0cmluZy1tYXRjaCAiXFwoWzAtOV0qXFwpXFwoWyorPV5dXFwp XFwoLis/XFwpXFwoWyxcbl1cXCkiIGd1ZC1tYXJrZXItYWNjIGdkYm1pLWJuZi1vZmZzZXQpKQoh IAohICAgICAgICAgKGxldCAoKHRva2VuIChtYXRjaC1zdHJpbmcgMSBndWQtbWFya2VyLWFjYykp CiEgCSAgICAgIChwcmVmaXggKG1hdGNoLXN0cmluZyAyIGd1ZC1tYXJrZXItYWNjKSkKISAJICAg ICAgKGNsYXNzIChtYXRjaC1zdHJpbmcgMyBndWQtbWFya2VyLWFjYykpCiEgCSAgICAgIChjb21w bGV0ZSAoc3RyaW5nLWVxdWFsIChtYXRjaC1zdHJpbmcgNCBndWQtbWFya2VyLWFjYykgIlxuIikp CiEgCSAgICAgIGNsYXNzLWFsaXN0CiEgCSAgICAgIGNsYXNzLWNvbW1hbmQpCiEgCiEgICAgICAg ICAgIChzZXRxIGdkYm1pLWJuZi1vZmZzZXQgKG1hdGNoLWVuZCAwKSkKISAJICAoaWYgZ2RibWkt ZGVidWctbW9kZSAobWVzc2FnZSAiZ2RibWktYm5mLXJlc3VsdC1yZWNvcmQ6ICVzIiAobWF0Y2gt c3RyaW5nIDAgZ3VkLW1hcmtlci1hY2MpKSkKISAKISAgICAgICAgICAgKHNldHEgY2xhc3MtYWxp c3QgKGNkciAoYXNzb2MgcHJlZml4IGdkYm1pLWJuZi1yZXN1bHQtc3RhdGUtY29uZmlncykpKQoh ICAgICAgICAgICAoc2V0cSBjbGFzcy1jb21tYW5kIChjZHIgKGFzc29jIGNsYXNzIGNsYXNzLWFs aXN0KSkpCiEgICAgICAgICAgIChpZiAobnVsbCBjbGFzcy1jb21tYW5kKQohICAgICAgICAgICAg ICAgKHNldHEgY2xhc3MtY29tbWFuZCAoY2RyIChhc3NvYyAnZGVmYXVsdCBjbGFzcy1hbGlzdCkp KSkKISAKISAgICAgICAgICAgKGlmIGNvbXBsZXRlCiEgICAgICAgICAgICAgICAoaWYgY2xhc3Mt Y29tbWFuZAohICAgICAgICAgICAgICAgICAgIChpZiAoZXF1YWwgKGNkciBjbGFzcy1jb21tYW5k KSAncHJvZ3Jlc3NpdmUpCiEgICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIChjYXIgY2xh c3MtY29tbWFuZCkgdG9rZW4gIiIgY29tcGxldGUpCiEgICAgICAgICAgICAgICAgICAgICAoZnVu Y2FsbCAoY2FyIGNsYXNzLWNvbW1hbmQpIHRva2VuICIiKSkpCiEgICAgICAgICAgICAgKHNldHEg Z2RibWktYm5mLXN0YXRlIGAobGFtYmRhICgpIChnZGJtaS1ibmYtaW5jb21wbGV0ZS1yZWNvcmQt cmVzdWx0ICx0b2tlbiAnLGNsYXNzLWNvbW1hbmQpKSkKISAgICAgICAgICAgICAoZnVuY2FsbCBn ZGJtaS1ibmYtc3RhdGUpKQohIAkgIHQpKSkpCiEgCiEgKGRlZnVuIGdkYm1pLWJuZi1pbmNvbXBs ZXRlLXJlY29yZC1yZXN1bHQgKHRva2VuIGNsYXNzLWNvbW1hbmQpCiEgICAiU3RhdGUgb2YgdGhl IHBhcnNlciB1c2VkIHRvIHByb2dyZXNzaXZlbHkgcGFyc2UgYSByZXN1bHQtcmVjb3JkIG9yIGFz eW5jLXJlY29yZAohIHJ1bGUgZnJvbSBhbiBpbmNvbXBsZXRlIGRhdGEgc3RyZWFtLiAgVGhlIHBh cnNlciB3aWxsIHN0YXkgaW4gdGhpcyBzdGF0ZSB1bnRpbCB0aGUgZW5kCiEgb2YgdGhlIGN1cnJl bnQgcmVzdWx0IG9yIGFzeW5jIHJlY29yZCBpcyByZWFjaGVkLiIKISAgICh3aGVuICg8IGdkYm1p LWJuZi1vZmZzZXQgKGxlbmd0aCBndWQtbWFya2VyLWFjYykpCiEgICAgIDs7IFNlYXJjaCB0aGUg ZGF0YSBzdHJlYW0gZm9yIHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgcmVjb3JkOgohICAgICAoaWYg KHN0cmluZy1tYXRjaCAiXFwoW15cbl0qXFwpXFwoXG4/XFwpIiBndWQtbWFya2VyLWFjYyBnZGJt aS1ibmYtb2Zmc2V0KQohIAohICAgICAgICAgKGxldCAoKHJlc3VsdCAobWF0Y2gtc3RyaW5nIDEg Z3VkLW1hcmtlci1hY2MpKQohICAgICAgICAgICAgICAgKGlzLWNvbXBsZXRlIChzdHJpbmctZXF1 YWwgKG1hdGNoLXN0cmluZyAyIGd1ZC1tYXJrZXItYWNjKSAiXG4iKSkKISAgICAgICAgICAgICAg IChpcy1wcm9ncmVzc2l2ZSAoZXF1YWwgKGNkciBjbGFzcy1jb21tYW5kKSAncHJvZ3Jlc3NpdmUp KSkKISAKISAgICAgICAgICAgOzsgVXBkYXRlIHRoZSBnZGJtaS1ibmYtb2Zmc2V0IG9ubHkgaWYg dGhlIGN1cnJlbnQgY2h1bmsgb2YgZGF0YSBjYW4KISAgICAgICAgICAgOzsgYmUgcHJvY2Vzc2Vk IGJ5IHRoZSBjbGFzcy1jb21tYW5kIGhhbmRsZXI6CiEgICAgICAgICAgIChpZiAob3IgaXMtY29t cGxldGUgaXMtcHJvZ3Jlc3NpdmUpCiEgICAgICAgICAgICAgICAoc2V0cSBnZGJtaS1ibmYtb2Zm c2V0IChtYXRjaC1lbmQgMCkpKQohIAohIAkgIChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdl ICJnZGJtaS1ibmYtaW5jb21wbGV0ZS1yZWNvcmQtcmVzdWx0OiAlcyIgKG1hdGNoLXN0cmluZyAw IGd1ZC1tYXJrZXItYWNjKSkpCiEgCiEgICAgICAgICAgIDs7IFVwZGF0ZSB0aGUgcGFyc2luZyBz dGF0ZSBiZWZvcmUgaW52b2tpbmcgdGhlIGhhbmRsZXIgaW4gY2xhc3MtY29tbWFuZAohICAgICAg ICAgICA7OyB0byBtYWtlIHN1cmUgaXQncyBub3QgbGVmdCBpbiBhbiBpbnZhbGlkIHN0YXRlIGlm IHRoZSBoYW5kbGVyIHdhcwohICAgICAgICAgICA7OyB0byBnZW5lcmF0ZSBhbiBlcnJvci4KISAg ICAgICAgICAgKGlmIGlzLWNvbXBsZXRlCiEgICAgICAgICAgICAgICAoc2V0cSBnZGJtaS1ibmYt c3RhdGUgJ2dkYm1pLWJuZi1vdXRwdXQpKQohIAohICAgICAgICAgICAoaWYgY2xhc3MtY29tbWFu ZAohICAgICAgICAgICAgICAgKGlmIGlzLXByb2dyZXNzaXZlCiEgICAgICAgICAgICAgICAgICAg KGZ1bmNhbGwgKGNhciBjbGFzcy1jb21tYW5kKSB0b2tlbiByZXN1bHQgaXMtY29tcGxldGUpCiEg ICAgICAgICAgICAgICAgIChpZiBpcy1jb21wbGV0ZQohICAgICAgICAgICAgICAgICAgICAgKGZ1 bmNhbGwgKGNhciBjbGFzcy1jb21tYW5kKSB0b2tlbiByZXN1bHQpKSkpCiEgCiEgICAgICAgICAg ICh1bmxlc3MgaXMtY29tcGxldGUgOzsgSW5jb21wbGV0ZSBnZGIgcmVzcG9uc2U6IGFib3J0IHRo ZSBwYXJzaW5nIHVudGlsIHdlIHJlY2VpdmUgbW9yZSBkYXRhLgohIAkgICAgKGlmIGdkYm1pLWRl YnVnLW1vZGUgKG1lc3NhZ2UgImdkYm1pLWJuZi1pbmNvbXBsZXRlLXJlY29yZC1yZXN1bHQsIGFi b3J0aW5nOiBpbmNvbXBsZXRlIHN0cmVhbSIpKQohICAgICAgICAgICAgICh0aHJvdyAnZ2RibWkt aW5jb21wbGV0ZS1zdHJlYW0gbmlsKSkKISAKISAgICAgICAgICAgaXMtY29tcGxldGUpKSkpCiEg CiEgCiEgOyBUaGUgZm9sbG93aW5nIGdyYW1tYXIgcnVsZXMgYXJlIG5vdCB5ZXQgaW1wbGVtZW50 ZWQgYnkgdGhpcyBHREJNSS1CTkYgcGFyc2VyLgohIDsgVGhlIGhhbmRsaW5nIG9mIHRob3NlIHJ1 bGVzIGlzIGN1cnJlbnRseSBkb25lIGJ5IHRoZSBoYW5kbGVycyByZWdpc3RlcmVkCiEgOyBpbiBn ZGJtaS1ibmYtcmVzdWx0LXN0YXRlLWNvbmZpZ3MKISA7CiEgOyByZXN1bHQgPT0+CiEgOyAgICAg IHZhcmlhYmxlICI9IiB2YWx1ZQohIDsKISA7IHZhcmlhYmxlID09PgohIDsgICAgICBzdHJpbmcK ISA7CiEgOyB2YWx1ZSA9PT4KISA7ICAgICAgY29uc3QgfCB0dXBsZSB8IGxpc3QKISA7CiEgOyBj b25zdCA9PT4KISA7ICAgICAgYy1zdHJpbmcKISA7CiEgOyB0dXBsZSA9PT4KISA7ICAgICAgInt9 IiB8ICJ7IiByZXN1bHQgKCAiLCIgcmVzdWx0ICkqICJ9IgohIDsKISA7IGxpc3QgPT0+CiEgOyAg ICAgICJbXSIgfCAiWyIgdmFsdWUgKCAiLCIgdmFsdWUgKSogIl0iIHwgIlsiIHJlc3VsdCAoICIs IiByZXN1bHQgKSogIl0iCiEgCiAgCiAgKGRlZnVuIGd1ZC1nZGJtaS1tYXJrZXItZmlsdGVyIChz dHJpbmcpCiAgICAiRmlsdGVyIEdEQi9NSSBvdXRwdXQuIgoqKioqKioqKioqKioqKiogaXMgcnVu bmluZy4iCioqKiAxOTA3LDE5NTIgKioqKgogIAogICAgOzsgU3RhcnQgYWNjdW11bGF0aW5nIG91 dHB1dCBmb3IgdGhlIEdVRCBidWZmZXIuCiAgICAoc2V0cSBnZGItZmlsdGVyLW91dHB1dCAiIikK LSAgIChsZXQgKG91dHB1dC1yZWNvcmQtbGlzdCkKICAKISAgICAgOzsgUHJvY2VzcyBhbGwgdGhl IGNvbXBsZXRlIG1hcmtlcnMgaW4gdGhpcyBjaHVuay4KISAgICAgKGRvbGlzdCAoZ2RibWktcmVj b3JkIGdkYm1pLXJlY29yZC1saXN0KQohICAgICAgICh3aGlsZSAoc3RyaW5nLW1hdGNoIChjZHIg Z2RibWktcmVjb3JkKSBndWQtbWFya2VyLWFjYykKISAJKHB1c2ggKGxpc3QgKG1hdGNoLWJlZ2lu bmluZyAwKQohIAkJICAgIChjYXIgZ2RibWktcmVjb3JkKQohIAkJICAgIChtYXRjaC1zdHJpbmcg MSBndWQtbWFya2VyLWFjYykKISAJCSAgICAobWF0Y2gtc3RyaW5nIDIgZ3VkLW1hcmtlci1hY2Mp CiEgCQkgICAgKG1hdGNoLWVuZCAwKSkKISAJICAgICAgb3V0cHV0LXJlY29yZC1saXN0KQohIAko c2V0cSBndWQtbWFya2VyLWFjYwohIAkgICAgICAoY29uY2F0IChzdWJzdHJpbmcgZ3VkLW1hcmtl ci1hY2MgMCAobWF0Y2gtYmVnaW5uaW5nIDApKQohIAkJICAgICAgOzsgUGFkIHdpdGggc3BhY2Vz IHRvIHByZXNlcnZlIHBvc2l0aW9uLgohIAkJICAgICAgKG1ha2Utc3RyaW5nIChsZW5ndGggKG1h dGNoLXN0cmluZyAwIGd1ZC1tYXJrZXItYWNjKSkgMzIpCiEgCQkgICAgICAoc3Vic3RyaW5nIGd1 ZC1tYXJrZXItYWNjIChtYXRjaC1lbmQgMCkpKSkpKQohIAohICAgICAoc2V0cSBvdXRwdXQtcmVj b3JkLWxpc3QgKHNvcnQgb3V0cHV0LXJlY29yZC1saXN0ICdnZGItY2FyPCkpCiEgCiEgICAgIChk b2xpc3QgKG91dHB1dC1yZWNvcmQgb3V0cHV0LXJlY29yZC1saXN0KQohICAgICAgIChsZXQgKChy ZWNvcmQtdHlwZSAoY2FkciBvdXRwdXQtcmVjb3JkKSkKISAJICAgIChhcmcxIChudGggMiBvdXRw dXQtcmVjb3JkKSkKISAJICAgIChhcmcyIChudGggMyBvdXRwdXQtcmVjb3JkKSkpCiEgCShjb25k ICgoZXEgcmVjb3JkLXR5cGUgJ2dkYi1lcnJvcikKISAJICAgICAgIChnZGItZG9uZS1vci1lcnJv ciBhcmcyIGFyZzEgJ2Vycm9yKSkKISAJICAgICAgKChlcSByZWNvcmQtdHlwZSAnZ2RiLWRvbmUp CiEgCSAgICAgICAoZ2RiLWRvbmUtb3ItZXJyb3IgYXJnMiBhcmcxICdkb25lKSkKISAJICAgICAg OzsgU3VwcHJlc3MgIk5vIHJlZ2lzdGVycy4iICBHREIgNi44IGFuZCBlYXJsaWVyCiEgCSAgICAg IDs7IGR1cGxpY2F0ZXMgTUkgZXJyb3IgbWVzc2FnZSBvbiBpbnRlcm5hbCBzdHJlYW0uCiEgCSAg ICAgIDs7IERvbid0IHByaW50IHRvIEdVRCBidWZmZXIuCiEgCSAgICAgICgobm90IChhbmQgKGVx IHJlY29yZC10eXBlICdnZGItaW50ZXJuYWxzKQohIAkJCSAoc3RyaW5nLWVxdWFsIChyZWFkIGFy ZzEpICJObyByZWdpc3RlcnMuXG4iKSkpCiEgCSAgICAgICAoZnVuY2FsbCByZWNvcmQtdHlwZSBh cmcxKSkpKSkKICAKISAgICAgKHNldHEgZ2RiLW91dHB1dC1zaW5rICd1c2VyKQohICAgICA7OyBS ZW1vdmUgcGFkZGluZy4KISAgICAgKHN0cmluZy1tYXRjaCAiXiAqIiBndWQtbWFya2VyLWFjYykK ISAgICAgKHNldHEgZ3VkLW1hcmtlci1hY2MgKHN1YnN0cmluZyBndWQtbWFya2VyLWFjYyAobWF0 Y2gtZW5kIDApKSkKICAKISAgICAgZ2RiLWZpbHRlci1vdXRwdXQpKQogIAogIChkZWZ1biBnZGIt Z2RiIChfb3V0cHV0LWZpZWxkKSkKICAKLS0tIDIyMTYsMjIzNCAtLS0tCiAgCiAgICA7OyBTdGFy dCBhY2N1bXVsYXRpbmcgb3V0cHV0IGZvciB0aGUgR1VEIGJ1ZmZlci4KICAgIChzZXRxIGdkYi1m aWx0ZXItb3V0cHV0ICIiKQogIAohICAgKGxldCAoKGFjYy1sZW5ndGggKGxlbmd0aCBndWQtbWFy a2VyLWFjYykpKQohICAgICAoY2F0Y2ggJ2dkYm1pLWluY29tcGxldGUtc3RyZWFtCiEgICAgICAg KHdoaWxlIChhbmQgKDwgZ2RibWktYm5mLW9mZnNldCBhY2MtbGVuZ3RoKQohIAkJICAoZnVuY2Fs bCBnZGJtaS1ibmYtc3RhdGUpKSkpKQogIAohICAgKHNldHEgZ3VkLW1hcmtlci1hY2MgKHN1YnN0 cmluZyBndWQtbWFya2VyLWFjYyBnZGJtaS1ibmYtb2Zmc2V0KSkKISAgIChzZXRxIGdkYm1pLWJu Zi1vZmZzZXQgMCkKISAKISAgICh3aGVuIChhbmQgZ2RibWktZGVidWctbW9kZSAoPiAobGVuZ3Ro IGd1ZC1tYXJrZXItYWNjKSAwKSkKISAgICAgKG1lc3NhZ2UgImd1ZC1nZGJtaS1tYXJrZXItZmls dGVyLCB1bnBhcnNlZCBzdHJpbmc6ICVzIiBndWQtbWFya2VyLWFjYykpCiAgCiEgICBnZGItZmls dGVyLW91dHB1dCkKICAKICAoZGVmdW4gZ2RiLWdkYiAoX291dHB1dC1maWVsZCkpCiAgCioqKioq KioqKioqKioqKiBpcyBydW5uaW5nLiIKKioqIDE5NTQsMTk2NCAqKioqCiAgICAoc2V0cSBnZGIt ZmlsdGVyLW91dHB1dAogICAgICAgICAgKGNvbmNhdCBvdXRwdXQtZmllbGQgZ2RiLWZpbHRlci1v dXRwdXQpKSkKICAKISAoZGVmdW4gZ2RiLWlnbm9yZWQtbm90aWZpY2F0aW9uIChfb3V0cHV0LWZp ZWxkKSkKICAKICA7OyBnZGItaW52YWxpZGF0ZS10aHJlYWRzIGlzIGRlZmluZWQgdG8gYWNjZXB0 ICd1cGRhdGUtdGhyZWFkcyBzaWduYWwKISAoZGVmdW4gZ2RiLXRocmVhZC1jcmVhdGVkIChfb3V0 cHV0LWZpZWxkKSkKISAoZGVmdW4gZ2RiLXRocmVhZC1leGl0ZWQgKG91dHB1dC1maWVsZCkKICAg ICJIYW5kbGUgPXRocmVhZC1leGl0ZWQgYXN5bmMgcmVjb3JkOiB1bnNldCBgZ2RiLXRocmVhZC1u dW1iZXInCiAgIGlmIGN1cnJlbnQgdGhyZWFkIGV4aXRlZCBhbmQgdXBkYXRlIHRocmVhZHMgbGlz dC4iCiAgICAobGV0KiAoKHRocmVhZC1pZCAoYmluZGF0LWdldC1maWVsZCAoZ2RiLWpzb24tc3Ry aW5nIG91dHB1dC1maWVsZCkgJ2lkKSkpCi0tLSAyMjM2LDIyNDYgLS0tLQogICAgKHNldHEgZ2Ri LWZpbHRlci1vdXRwdXQKICAgICAgICAgIChjb25jYXQgb3V0cHV0LWZpZWxkIGdkYi1maWx0ZXIt b3V0cHV0KSkpCiAgCiEgKGRlZnVuIGdkYi1pZ25vcmVkLW5vdGlmaWNhdGlvbiAoX3Rva2VuIF9v dXRwdXQtZmllbGQpKQogIAogIDs7IGdkYi1pbnZhbGlkYXRlLXRocmVhZHMgaXMgZGVmaW5lZCB0 byBhY2NlcHQgJ3VwZGF0ZS10aHJlYWRzIHNpZ25hbAohIChkZWZ1biBnZGItdGhyZWFkLWNyZWF0 ZWQgKF90b2tlbiBfb3V0cHV0LWZpZWxkKSkKISAoZGVmdW4gZ2RiLXRocmVhZC1leGl0ZWQgKF90 b2tlbiBvdXRwdXQtZmllbGQpCiAgICAiSGFuZGxlID10aHJlYWQtZXhpdGVkIGFzeW5jIHJlY29y ZDogdW5zZXQgYGdkYi10aHJlYWQtbnVtYmVyJwogICBpZiBjdXJyZW50IHRocmVhZCBleGl0ZWQg YW5kIHVwZGF0ZSB0aHJlYWRzIGxpc3QuIgogICAgKGxldCogKCh0aHJlYWQtaWQgKGJpbmRhdC1n ZXQtZmllbGQgKGdkYi1qc29uLXN0cmluZyBvdXRwdXQtZmllbGQpICdpZCkpKQoqKioqKioqKioq KioqKiogaXMgcnVubmluZy4iCioqKiAxOTcxLDE5NzcgKioqKgogICAgICAoZ2RiLXdhaXQtZm9y LXBlbmRpbmcKICAgICAgIChnZGItZW1pdC1zaWduYWwgZ2RiLWJ1Zi1wdWJsaXNoZXIgJ3VwZGF0 ZS10aHJlYWRzKSkpKQogIAohIChkZWZ1biBnZGItdGhyZWFkLXNlbGVjdGVkIChvdXRwdXQtZmll bGQpCiAgICAiSGFuZGxlciBmb3IgPXRocmVhZC1zZWxlY3RlZCBNSSBvdXRwdXQgcmVjb3JkLgog IAogIFNldHMgYGdkYi10aHJlYWQtbnVtYmVyJyB0byBuZXcgaWQuIgotLS0gMjI1MywyMjU5IC0t LS0KICAgICAgKGdkYi13YWl0LWZvci1wZW5kaW5nCiAgICAgICAoZ2RiLWVtaXQtc2lnbmFsIGdk Yi1idWYtcHVibGlzaGVyICd1cGRhdGUtdGhyZWFkcykpKSkKICAKISAoZGVmdW4gZ2RiLXRocmVh ZC1zZWxlY3RlZCAoX3Rva2VuIG91dHB1dC1maWVsZCkKICAgICJIYW5kbGVyIGZvciA9dGhyZWFk LXNlbGVjdGVkIE1JIG91dHB1dCByZWNvcmQuCiAgCiAgU2V0cyBgZ2RiLXRocmVhZC1udW1iZXIn IHRvIG5ldyBpZC4iCioqKioqKioqKioqKioqKiBTZXRzIGBnZGItdGhyZWFkLW51bWJlcicgdG8g bmV3IGlkLiIKKioqIDE5ODgsMTk5NCAqKioqCiAgICAgIChnZGItd2FpdC1mb3ItcGVuZGluZwog ICAgICAgKGdkYi11cGRhdGUpKSkpCiAgCiEgKGRlZnVuIGdkYi1ydW5uaW5nIChvdXRwdXQtZmll bGQpCiAgICAobGV0KiAoKHRocmVhZC1pZAogICAgICAgICAgICAoYmluZGF0LWdldC1maWVsZCAo Z2RiLWpzb24tc3RyaW5nIG91dHB1dC1maWVsZCkgJ3RocmVhZC1pZCkpKQogICAgICA7OyBXZSBy ZXNldCBnZGItZnJhbWUtbnVtYmVyIHRvIG5pbCBpZiBjdXJyZW50IHRocmVhZCBoYXMgZ29uZQot LS0gMjI3MCwyMjc2IC0tLS0KICAgICAgKGdkYi13YWl0LWZvci1wZW5kaW5nCiAgICAgICAoZ2Ri LXVwZGF0ZSkpKSkKICAKISAoZGVmdW4gZ2RiLXJ1bm5pbmcgKF90b2tlbiBvdXRwdXQtZmllbGQp CiAgICAobGV0KiAoKHRocmVhZC1pZAogICAgICAgICAgICAoYmluZGF0LWdldC1maWVsZCAoZ2Ri LWpzb24tc3RyaW5nIG91dHB1dC1maWVsZCkgJ3RocmVhZC1pZCkpKQogICAgICA7OyBXZSByZXNl dCBnZGItZnJhbWUtbnVtYmVyIHRvIG5pbCBpZiBjdXJyZW50IHRocmVhZCBoYXMgZ29uZQoqKioq KioqKioqKioqKiogU2V0cyBgZ2RiLXRocmVhZC1udW1iZXInIHRvIG5ldyBpZC4iCioqKiAyMDA2 LDIwMTIgKioqKgogICAgKHNldHEgZ2RiLWFjdGl2ZS1wcm9jZXNzIHQpCiAgICAoZ2RiLWVtaXQt c2lnbmFsIGdkYi1idWYtcHVibGlzaGVyICd1cGRhdGUtdGhyZWFkcykpCiAgCiEgKGRlZnVuIGdk Yi1zdGFydGluZyAoX291dHB1dC1maWVsZCkKICAgIDs7IENMSSBjb21tYW5kcyBkb24ndCBlbWl0 IF5ydW5uaW5nIGF0IHRoZSBtb21lbnQgc28gdXNlIGdkYi1ydW5uaW5nIHRvby4KICAgIChzZXRx IGdkYi1pbmZlcmlvci1zdGF0dXMgInJ1bm5pbmciKQogICAgKGdkYi1mb3JjZS1tb2RlLWxpbmUt dXBkYXRlCi0tLSAyMjg4LDIyOTQgLS0tLQogICAgKHNldHEgZ2RiLWFjdGl2ZS1wcm9jZXNzIHQp CiAgICAoZ2RiLWVtaXQtc2lnbmFsIGdkYi1idWYtcHVibGlzaGVyICd1cGRhdGUtdGhyZWFkcykp CiAgCiEgKGRlZnVuIGdkYi1zdGFydGluZyAoX291dHB1dC1maWVsZCByZXN1bHQpCiAgICA7OyBD TEkgY29tbWFuZHMgZG9uJ3QgZW1pdCBecnVubmluZyBhdCB0aGUgbW9tZW50IHNvIHVzZSBnZGIt cnVubmluZyB0b28uCiAgICAoc2V0cSBnZGItaW5mZXJpb3Itc3RhdHVzICJydW5uaW5nIikKICAg IChnZGItZm9yY2UtbW9kZS1saW5lLXVwZGF0ZQoqKioqKioqKioqKioqKiogU2V0cyBgZ2RiLXRo cmVhZC1udW1iZXInIHRvIG5ldyBpZC4iCioqKiAyMDIwLDIwMjYgKioqKgogIAogIDs7IC1icmVh ay1pbnNlcnQgLXQgZGlkbid0IGdpdmUgYSByZWFzb24gYmVmb3JlIGdkYiA2LjkKICAKISAoZGVm dW4gZ2RiLXN0b3BwZWQgKG91dHB1dC1maWVsZCkKICAgICJHaXZlbiB0aGUgY29udGVudHMgb2Yg KnN0b3BwZWQgTUkgYXN5bmMgcmVjb3JkLCBzZWxlY3QgbmV3CiAgY3VycmVudCB0aHJlYWQgYW5k IHVwZGF0ZSBHREIgYnVmZmVycy4iCiAgICA7OyBSZWFzb24gaXMgYXZhaWxhYmxlIHdpdGggdGFy Z2V0LWFzeW5jIG9ubHkKLS0tIDIzMDIsMjMwOCAtLS0tCiAgCiAgOzsgLWJyZWFrLWluc2VydCAt dCBkaWRuJ3QgZ2l2ZSBhIHJlYXNvbiBiZWZvcmUgZ2RiIDYuOQogIAohIChkZWZ1biBnZGItc3Rv cHBlZCAoX3Rva2VuIG91dHB1dC1maWVsZCkKICAgICJHaXZlbiB0aGUgY29udGVudHMgb2YgKnN0 b3BwZWQgTUkgYXN5bmMgcmVjb3JkLCBzZWxlY3QgbmV3CiAgY3VycmVudCB0aHJlYWQgYW5kIHVw ZGF0ZSBHREIgYnVmZmVycy4iCiAgICA7OyBSZWFzb24gaXMgYXZhaWxhYmxlIHdpdGggdGFyZ2V0 LWFzeW5jIG9ubHkKKioqKioqKioqKioqKioqIGN1cnJlbnQgdGhyZWFkIGFuZCB1cGRhdGUgR0RC IGJ1ZmZlcnMuIgoqKiogMjEwNiwyMTEyICoqKioKICAgIChzZXRxIGdkYi1maWx0ZXItb3V0cHV0 CiAgCShnZGItY29uY2F0LW91dHB1dCBnZGItZmlsdGVyLW91dHB1dCAocmVhZCBvdXRwdXQtZmll bGQpKSkpCiAgCiEgKGRlZnVuIGdkYi1kb25lLW9yLWVycm9yIChvdXRwdXQtZmllbGQgdG9rZW4t bnVtYmVyIHR5cGUpCiAgICAoaWYgKHN0cmluZy1lcXVhbCB0b2tlbi1udW1iZXIgIiIpCiAgICAg ICAgOzsgT3V0cHV0IGZyb20gY29tbWFuZCBlbnRlcmVkIGJ5IHVzZXIKICAgICAgICAocHJvZ24K LS0tIDIzODgsMjQwMCAtLS0tCiAgICAoc2V0cSBnZGItZmlsdGVyLW91dHB1dAogIAkoZ2RiLWNv bmNhdC1vdXRwdXQgZ2RiLWZpbHRlci1vdXRwdXQgKHJlYWQgb3V0cHV0LWZpZWxkKSkpKQogIAoh IChkZWZ1biBnZGItZG9uZSAodG9rZW4tbnVtYmVyIG91dHB1dC1maWVsZCBpcy1jb21wbGV0ZSkK ISAgIChnZGItZG9uZS1vci1lcnJvciB0b2tlbi1udW1iZXIgJ2RvbmUgb3V0cHV0LWZpZWxkIGlz LWNvbXBsZXRlKSkKISAKISAoZGVmdW4gZ2RiLWVycm9yICh0b2tlbi1udW1iZXIgb3V0cHV0LWZp ZWxkIGlzLWNvbXBsZXRlKQohICAgKGdkYi1kb25lLW9yLWVycm9yIHRva2VuLW51bWJlciAnZXJy b3Igb3V0cHV0LWZpZWxkIGlzLWNvbXBsZXRlKSkKISAKISAoZGVmdW4gZ2RiLWRvbmUtb3ItZXJy b3IgKHRva2VuLW51bWJlciB0eXBlIG91dHB1dC1maWVsZCBpcy1jb21wbGV0ZSkKICAgIChpZiAo c3RyaW5nLWVxdWFsIHRva2VuLW51bWJlciAiIikKICAgICAgICA7OyBPdXRwdXQgZnJvbSBjb21t YW5kIGVudGVyZWQgYnkgdXNlcgogICAgICAgIChwcm9nbgoqKioqKioqKioqKioqKiogY3VycmVu dCB0aHJlYWQgYW5kIHVwZGF0ZSBHREIgYnVmZmVycy4iCioqKiAyMTIyLDIxMzUgKioqKgogICAg ICA7OyBPdXRwdXQgZnJvbSBjb21tYW5kIGZyb20gZnJvbnRlbmQuCiAgICAgIChzZXRxIGdkYi1v dXRwdXQtc2luayAnZW1hY3MpKQogIAotICAgKGdkYi1jbGVhci1wYXJ0aWFsLW91dHB1dCkKLSAK ICAgIDs7IFRoZSBwcm9jZXNzIG1heSBhbHJlYWR5IGJlIGRlYWQgKGUuZy4gQy1kIGF0IHRoZSBn ZGIgcHJvbXB0KS4KICAgIChsZXQqICgocHJvYyAoZ2V0LWJ1ZmZlci1wcm9jZXNzIGd1ZC1jb21p bnQtYnVmZmVyKSkKICAJIChuby1wcm9jIChvciAobnVsbCBwcm9jKQogIAkJICAgICAgKG1lbXEg KHByb2Nlc3Mtc3RhdHVzIHByb2MpICcoZXhpdCBzaWduYWwpKSkpKQogIAohICAgICAod2hlbiBn ZGItZmlyc3QtZG9uZS1vci1lcnJvcgogICAgICAgICh1bmxlc3MgKG9yIHRva2VuLW51bWJlciBn dWQtcnVubmluZyBuby1wcm9jKQogIAkoc2V0cSBnZGItZmlsdGVyLW91dHB1dCAoY29uY2F0IGdk Yi1maWx0ZXItb3V0cHV0IGdkYi1wcm9tcHQtbmFtZSkpKQogICAgICAgIChnZGItdXBkYXRlIG5v LXByb2MpCi0tLSAyNDEwLDI0MjEgLS0tLQogICAgICA7OyBPdXRwdXQgZnJvbSBjb21tYW5kIGZy b20gZnJvbnRlbmQuCiAgICAgIChzZXRxIGdkYi1vdXRwdXQtc2luayAnZW1hY3MpKQogIAogICAg OzsgVGhlIHByb2Nlc3MgbWF5IGFscmVhZHkgYmUgZGVhZCAoZS5nLiBDLWQgYXQgdGhlIGdkYiBw cm9tcHQpLgogICAgKGxldCogKChwcm9jIChnZXQtYnVmZmVyLXByb2Nlc3MgZ3VkLWNvbWludC1i dWZmZXIpKQogIAkgKG5vLXByb2MgKG9yIChudWxsIHByb2MpCiAgCQkgICAgICAobWVtcSAocHJv Y2Vzcy1zdGF0dXMgcHJvYykgJyhleGl0IHNpZ25hbCkpKSkpCiAgCiEgICAgICh3aGVuIChhbmQg aXMtY29tcGxldGUgZ2RiLWZpcnN0LWRvbmUtb3ItZXJyb3IpCiAgICAgICAgKHVubGVzcyAob3Ig dG9rZW4tbnVtYmVyIGd1ZC1ydW5uaW5nIG5vLXByb2MpCiAgCShzZXRxIGdkYi1maWx0ZXItb3V0 cHV0IChjb25jYXQgZ2RiLWZpbHRlci1vdXRwdXQgZ2RiLXByb21wdC1uYW1lKSkpCiAgICAgICAg KGdkYi11cGRhdGUgbm8tcHJvYykKKioqKioqKioqKioqKioqIGN1cnJlbnQgdGhyZWFkIGFuZCB1 cGRhdGUgR0RCIGJ1ZmZlcnMuIgoqKiogMjEzOCwyMTUwICoqKioKICAgICAgKHNldHEgZ2RiLWZp bHRlci1vdXRwdXQKICAJICAoZ2RiLWNvbmNhdC1vdXRwdXQgZ2RiLWZpbHRlci1vdXRwdXQgb3V0 cHV0LWZpZWxkKSkKICAKISAgICAgKHdoZW4gdG9rZW4tbnVtYmVyCiAgICAgICAgKHdpdGgtY3Vy cmVudC1idWZmZXIKICAJICAoZ2RiLWdldC1idWZmZXItY3JlYXRlICdnZGItcGFydGlhbC1vdXRw dXQtYnVmZmVyKQogIAkoZnVuY2FsbAogIAkgKGNkciAoYXNzb2MgKHN0cmluZy10by1udW1iZXIg dG9rZW4tbnVtYmVyKSBnZGItaGFuZGxlci1hbGlzdCkpKSkKICAgICAgICAoc2V0cSBnZGItaGFu ZGxlci1hbGlzdAohIAkgICAgKGFzc3EtZGVsZXRlLWFsbCB0b2tlbi1udW1iZXIgZ2RiLWhhbmRs ZXItYWxpc3QpKSkpKQogIAogIChkZWZ1biBnZGItY29uY2F0LW91dHB1dCAoc28tZmFyIG5ldykK ICAgIChjb25kCi0tLSAyNDI0LDI0NDIgLS0tLQogICAgICAoc2V0cSBnZGItZmlsdGVyLW91dHB1 dAogIAkgIChnZGItY29uY2F0LW91dHB1dCBnZGItZmlsdGVyLW91dHB1dCBvdXRwdXQtZmllbGQp KQogIAohICAgICA7OyBXZSBhcmUgZG9uZSBjb25jYXRlbmF0aW5nIHRvIHRoZSBvdXRwdXQgc2lu ay4gIFJlc3RvcmUgaXQgdG8gdXNlciBzaW5rOgohICAgICAoc2V0cSBnZGItb3V0cHV0LXNpbmsg J3VzZXIpCiEgCiEgICAgICh3aGVuIChhbmQgdG9rZW4tbnVtYmVyIGlzLWNvbXBsZXRlKQogICAg ICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyCiAgCSAgKGdkYi1nZXQtYnVmZmVyLWNyZWF0ZSAnZ2Ri LXBhcnRpYWwtb3V0cHV0LWJ1ZmZlcikKICAJKGZ1bmNhbGwKICAJIChjZHIgKGFzc29jIChzdHJp bmctdG8tbnVtYmVyIHRva2VuLW51bWJlcikgZ2RiLWhhbmRsZXItYWxpc3QpKSkpCiAgICAgICAg KHNldHEgZ2RiLWhhbmRsZXItYWxpc3QKISAgICAgICAgICAgICAoYXNzcS1kZWxldGUtYWxsIHRv a2VuLW51bWJlciBnZGItaGFuZGxlci1hbGlzdCkpKQohIAohICAgKHdoZW4gaXMtY29tcGxldGUK ISAgICAgKGdkYi1jbGVhci1wYXJ0aWFsLW91dHB1dCkpKSkKICAKICAoZGVmdW4gZ2RiLWNvbmNh dC1vdXRwdXQgKHNvLWZhciBuZXcpCiAgICAoY29uZAoK --20cf307f34120b857404d1192c1b-- From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 18 13:41:16 2012 Received: (at control) by debbugs.gnu.org; 18 Dec 2012 18:41:16 +0000 Received: from localhost ([127.0.0.1]:49470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl26N-0007fv-NF for submit@debbugs.gnu.org; Tue, 18 Dec 2012 13:41:16 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:47277) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tl26L-0007fo-Dm for control@debbugs.gnu.org; Tue, 18 Dec 2012 13:41:13 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1Tl251-0002jd-KR for control@debbugs.gnu.org; Tue, 18 Dec 2012 13:39:51 -0500 Date: Tue, 18 Dec 2012 13:39:51 -0500 Message-Id: Subject: control message for bug 10580 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) severity 10580 important tag 10580 patch From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 20 23:01:25 2012 Received: (at 10580) by debbugs.gnu.org; 21 Dec 2012 04:01:25 +0000 Received: from localhost ([127.0.0.1]:53286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TltnY-0005Tc-T2 for submit@debbugs.gnu.org; Thu, 20 Dec 2012 23:01:25 -0500 Received: from mail-pb0-f46.google.com ([209.85.160.46]:41903) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TltnW-0005TU-1u for 10580@debbugs.gnu.org; Thu, 20 Dec 2012 23:01:23 -0500 Received: by mail-pb0-f46.google.com with SMTP id wy7so2417445pbc.5 for <10580@debbugs.gnu.org>; Thu, 20 Dec 2012 20:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=2beePCpSD/lpMe+fpqd1muWFUZ5ZLdmOSf9vBq5BrFE=; b=an35kPTUMYD5T/ejou3njh2fS+6SjLUQk4EfrnUX8+J3oSgvQKxXJXSCbnP4W057Gq jn+eO44heIFH/P6Ss2NQmJ2EOeKaqfb7E2w47LT+Anmwbopwgxmmx18mv5VqZgMSplit ZOxkm6zpDHCfz7mcUXBL/tkODNyxSpB9fwMRwGKmfo2aI0ReGgkSp/gCmbm5Ce1R+qR4 4nwWvii5bwd9ezResR+jtNXVFzSF6vgzX4N0AZBBlk9OK4fBDsT9inYIG/36LEbYLYun GsH4kvcvaN/THo09iZ4x416k/d+WfwZNapt/S4aAKfb2JM8Xvy0Ch7HNH7cPxqp2NUjj Yfxg== X-Received: by 10.68.209.136 with SMTP id mm8mr35711331pbc.146.1356062470031; Thu, 20 Dec 2012 20:01:10 -0800 (PST) Received: from ulysses ([155.69.18.203]) by mx.google.com with ESMTPS id jo6sm2495203pbb.5.2012.12.20.20.01.06 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 20:01:08 -0800 (PST) From: Chong Yidong To: Jean-Philippe Gravel Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100 References: Date: Fri, 21 Dec 2012 12:01:04 +0800 In-Reply-To: (Jean-Philippe Gravel's message of "Mon, 17 Dec 2012 23:45:49 -0500") Message-ID: <87pq242gvz.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 10580 Cc: 10580@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Jean-Philippe Gravel writes: > As stated previously, I only re-wrote gud-gdbmi-marker-filter. This > function now parses the GDB/MI records in the order of arrival. Only > the signature of each record is read by the new parser. The actual > content of the record (i.e. result strings) is still parsed by the > original code (which I will refer to as the record handlers below). > > The new parser is based on the GDB/MI output BNF grammar available at: > ftp://ftp.gnu.org/pub/old-gnu/Manuals/gdb/html_node/gdb_214.html#SEC221 Thanks. This looks like a very good change indeed. In order for us to include it in Emacs, we need a copyright assignment; I hope you will be willing to sign one. I will contact you off-list about how to do this. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 28 22:33:09 2013 Received: (at 10580) by debbugs.gnu.org; 1 Mar 2013 03:33:09 +0000 Received: from localhost ([127.0.0.1]:57103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UBGia-0002Kk-VT for submit@debbugs.gnu.org; Thu, 28 Feb 2013 22:33:09 -0500 Received: from mail-bk0-f42.google.com ([209.85.214.42]:59581) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UBGiW-0002Ka-OC for 10580@debbugs.gnu.org; Thu, 28 Feb 2013 22:33:05 -0500 Received: by mail-bk0-f42.google.com with SMTP id jk7so1160969bkc.1 for <10580@debbugs.gnu.org>; Thu, 28 Feb 2013 19:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y8UXjyAdbAbaWvOoxST+Uu2goV4iJKqkMyFgQfD/5LE=; b=nWlTiG1Rq+UIyxUDc8yfyREzRzoopNSV9htWht0XTWJ85cJg51dmhjqPEvgbGUFejZ MRhi9DOeI2IrbICua/NyY6ByQzkxMjfiJvriD/Cqd/6fUYZasdMBGT4FiG43xIU85cFi /ZbNjGwrNDp1RPejX1ZrfeQmrMQ4/clAC8d2fku+1gRtkkRcztavTd68hTJJF/tSbdYL YcnjrIpZcPPB4jEZ8/bDPTifsR5+KwO+cNw1FU3PjibhuhU5Q6bAfAz0cMG0+rV+qrid UZ5qEF6DYUUFk6sTvoIWzJgrfTkeoWC2wxJhR+4tJB34lDN6kEgm3QeaW9eBEjFdBYdW 4raA== MIME-Version: 1.0 X-Received: by 10.204.156.206 with SMTP id y14mr3260708bkw.34.1362108664193; Thu, 28 Feb 2013 19:31:04 -0800 (PST) Received: by 10.204.195.71 with HTTP; Thu, 28 Feb 2013 19:31:03 -0800 (PST) In-Reply-To: <87pq242gvz.fsf@gnu.org> References: <87pq242gvz.fsf@gnu.org> Date: Thu, 28 Feb 2013 22:31:03 -0500 Message-ID: Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100 From: Jean-Philippe Gravel To: 10580@debbugs.gnu.org Content-Type: multipart/mixed; boundary=0015175cf87813586404d6d4a32f X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 10580 Cc: Chong Yidong X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) --0015175cf87813586404d6d4a32f Content-Type: text/plain; charset=ISO-8859-1 > Thanks. This looks like a very good change indeed. In order for us to > include it in Emacs, we need a copyright assignment; I hope you will be > willing to sign one. I will contact you off-list about how to do this. My copyright assignment is finally complete. While I was waiting for that, I found a problem with my patch. If you use the gdb command "finish" to exit from a function, gdb replies with a dump of the returned value (even though gdb-mi will not show it). My previous patch was failing with a regexp overflow if the return value was too big. This new patch will solve this problem. --0015175cf87813586404d6d4a32f Content-Type: application/octet-stream; name="gdb-mi-optimization-2.patch" Content-Disposition: attachment; filename="gdb-mi-optimization-2.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hdqs3axl0 KioqIHRydW5rL2xpc3AvcHJvZ21vZGVzL2dkYi1taS5lbAkyMDEzLTAxLTI1IDIzOjEyOjAwLjA2 NTc1ODI1NyAtMDUwMAotLS0gdHJ1bmstZGV2L2xpc3AvcHJvZ21vZGVzL2dkYi1taS5lbAkyMDEz LTAyLTI4IDIxOjI5OjE1LjYzNDA2MzY3NyAtMDUwMAoqKioqKioqKioqKioqKioKKioqIDUwNyw1 MTIgKioqKgotLS0gNTA3LDUxOSAtLS0tCiAgICA6Z3JvdXAgJ2dkYgogICAgOnZlcnNpb24gIjIy LjEiKQogIAorIChkZWZjdXN0b20gZ2RibWktZGVidWctbW9kZSBuaWwKKyAgICJXaGVuIG5vbi1u aWwsIGFsbCB0aGUgbWVzc2FnZXMgc2VudCBvciByZWNlaXZlZCBmcm9tIEdEQi9NSSBhcmUgcHJp bnRlZCBpbgorIHRoZSAqTWVzc2FnZXMqIGJ1ZmZlci4iCisgICA6dHlwZSAnYm9vbGVhbgorICAg Omdyb3VwICdndWQKKyAgIDp2ZXJzaW9uICIyNC4zIikKKyAKICAoZGVmdW4gZ2RiLWZvcmNlLW1v ZGUtbGluZS11cGRhdGUgKHN0YXR1cykKICAgIChsZXQgKChidWZmZXIgZ3VkLWNvbWludC1idWZm ZXIpKQogICAgICAoaWYgKGFuZCBidWZmZXIgKGJ1ZmZlci1uYW1lIGJ1ZmZlcikpCioqKioqKioq KioqKioqKgoqKiogODQ2LDg1MSAqKioqCi0tLSA4NTMsODYwIC0tLS0KICAgICAgICAgIGdkYi1y ZWdpc3Rlci1uYW1lcyAnKCkKICAgICAgICAgIGdkYi1ub24tc3RvcCBnZGItbm9uLXN0b3Atc2V0 dGluZykKICAgIDs7CisgICAoZ2RibWktYm5mLWluaXQpCisgICA7OwogICAgKHNldHEgZ2RiLWJ1 ZmZlci10eXBlICdnZGJtaSkKICAgIDs7CiAgICAoZ2RiLWZvcmNlLW1vZGUtbGluZS11cGRhdGUK KioqKioqKioqKioqKioqCioqKiAxNzM5LDE3NDQgKioqKgotLS0gMTc0OCwxNzU0IC0tLS0KICAg IChzZXRxIGdkYi10b2tlbi1udW1iZXIgKDErIGdkYi10b2tlbi1udW1iZXIpKQogICAgKHNldHEg Y29tbWFuZCAoY29uY2F0IChudW1iZXItdG8tc3RyaW5nIGdkYi10b2tlbi1udW1iZXIpIGNvbW1h bmQpKQogICAgKHB1c2ggKGNvbnMgZ2RiLXRva2VuLW51bWJlciBoYW5kbGVyLWZ1bmN0aW9uKSBn ZGItaGFuZGxlci1hbGlzdCkKKyAgIChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJnZGIt aW5wdXQ6ICVzIiBjb21tYW5kKSkKICAgIChwcm9jZXNzLXNlbmQtc3RyaW5nIChnZXQtYnVmZmVy LXByb2Nlc3MgZ3VkLWNvbWludC1idWZmZXIpCiAgCQkgICAgICAgKGNvbmNhdCBjb21tYW5kICJc biIpKSkKICAKKioqKioqKioqKioqKioqCioqKiAxODc0LDE4OTYgKioqKgogICAgICAgIChzZXQt d2luZG93LWJ1ZmZlciBzb3VyY2Utd2luZG93IGJ1ZmZlcikpCiAgICAgIHNvdXJjZS13aW5kb3cp KQogIAotIChkZWZ1biBnZGItY2FyPCAoYSBiKQotICAgKDwgKGNhciBhKSAoY2FyIGIpKSkKICAK ISAoZGVmdmFyIGdkYm1pLXJlY29yZC1saXN0CiEgICAnKChnZGItZ2RiIC4gIihnZGIpIFxuIikK ISAgICAgKGdkYi1kb25lIC4gIlxcKFswLTldKlxcKVxcXmRvbmUsP1xcKC4qP1xcKVxuIikKISAg ICAgKGdkYi1zdGFydGluZyAuICJcXChbMC05XSpcXClcXF5ydW5uaW5nXG4iKQohICAgICAoZ2Ri LWVycm9yIC4gIlxcKFswLTldKlxcKVxcXmVycm9yLFxcKC4qP1xcKVxuIikKISAgICAgKGdkYi1j b25zb2xlIC4gIn5cXChcIi4qP1wiXFwpXG4iKQohICAgICAoZ2RiLWludGVybmFscyAuICImXFwo XCIuKj9cIlxcKVxuIikKISAgICAgKGdkYi1zdG9wcGVkIC4gIlxcKnN0b3BwZWQsP1xcKC4qP1xc KVxuIikKISAgICAgKGdkYi1ydW5uaW5nIC4gIlxcKnJ1bm5pbmcsXFwoLio/XG5cXCkiKQohICAg ICAoZ2RiLXRocmVhZC1jcmVhdGVkIC4gIj10aHJlYWQtY3JlYXRlZCxcXCguKj9cblxcKSIpCiEg ICAgIChnZGItdGhyZWFkLXNlbGVjdGVkIC4gIj10aHJlYWQtc2VsZWN0ZWQsXFwoLio/XFwpXG4i KQohICAgICAoZ2RiLXRocmVhZC1leGl0ZWQgLiAiPXRocmVhZC1leGl0ZWQsXFwoLio/XG5cXCki KQohICAgICAoZ2RiLWlnbm9yZWQtbm90aWZpY2F0aW9uIC4gIj1bLVs6YWxwaGE6XV0rLD9cXCgu Kj9cXClcbiIpCiEgICAgIChnZGItc2hlbGwgLiAiXFwoXFwoPzpeLitcblxcKStcXCkiKSkpCiAg CiAgKGRlZnVuIGd1ZC1nZGJtaS1tYXJrZXItZmlsdGVyIChzdHJpbmcpCiAgICAiRmlsdGVyIEdE Qi9NSSBvdXRwdXQuIgotLS0gMTg4NCwyMjA1IC0tLS0KICAgICAgICAoc2V0LXdpbmRvdy1idWZm ZXIgc291cmNlLXdpbmRvdyBidWZmZXIpKQogICAgICBzb3VyY2Utd2luZG93KSkKICAKICAKISAo ZGVmdW4gZ2RibWktc3RhcnQtd2l0aCAoc3RyIG9mZnNldCBtYXRjaCkKISAgICJSZXR1cm5zIG5v bi1uaWwgaWYgc3RyaW5nIFNUUiBzdGFydHMgd2l0aCBNQVRDSCwgZWxzZSByZXR1cm5zIG5pbC4K ISBPRkZTRVQgaXMgdGhlIHBvc2l0aW9uIGluIFNUUiBhdCB3aGljaCB0aGUgY29tcGFyaXNvbiB0 YWtlcyBwbGFjZS4iCiEgICAobGV0ICgobWF0Y2gtbGVuZ3RoIChsZW5ndGggbWF0Y2gpKQohIAko c3RyLWxlbmd0aCAoLSAobGVuZ3RoIHN0cikgb2Zmc2V0KSkpCiEgICAgICh3aGVuICg+PSBzdHIt bGVuZ3RoIG1hdGNoLWxlbmd0aCkKISAgICAgICAoc3RyaW5nLWVxdWFsIG1hdGNoIChzdWJzdHJp bmcgc3RyIG9mZnNldCAoKyBvZmZzZXQgbWF0Y2gtbGVuZ3RoKSkpKSkpCiEgCiEgKGRlZnVuIGdk Ym1pLXNhbWUtc3RhcnQgKHN0ciBvZmZzZXQgbWF0Y2gpCiEgICAiUmV0dXJucyBub24tbmlsIGlm IFNUUiBhbmQgTUFUQ0ggYXJlIGVxdWFsIHVwIHRvIHRoZSBlbmQgb2YgZWl0aGVyIHN0cmluZ3Ms IGVsc2UgcmV0dXJucyBuaWwuCiEgT0ZGU0VUIGlzIHRoZSBwb3NpdGlvbiBpbiBTVFIgYXQgd2hp Y2ggdGhlIGNvbXBhcmlzb24gdGFrZXMgcGxhY2UuIgohICAgKGxldCogKChzdHItbGVuZ3RoICgt IChsZW5ndGggc3RyKSBvZmZzZXQpKQohIAkgKG1hdGNoLWxlbmd0aCAobGVuZ3RoIG1hdGNoKSkK ISAJIChjb21wYXJlLWxlbmd0aCAobWluIHN0ci1sZW5ndGggbWF0Y2gtbGVuZ3RoKSkpCiEgICAg ICh3aGVuICg+IGNvbXBhcmUtbGVuZ3RoIDApCiEgICAgICAgKHN0cmluZy1lcXVhbCAoc3Vic3Ry aW5nIHN0ciBvZmZzZXQgKCsgb2Zmc2V0IGNvbXBhcmUtbGVuZ3RoKSkKISAJCSAgICAoc3Vic3Ry aW5nIG1hdGNoIDAgY29tcGFyZS1sZW5ndGgpKSkpKQohIAohIChkZWZ1biBnZGJtaS1pcy1udW1i ZXIgKGNoYXJhY3RlcikKISAiUmV0dXJucyBub24tbmlsIGlmIENIQVJBQ1RFUiBpcyBhIG51bWVy aWNhbCBjaGFyYWN0ZXIgYmV0d2VlbiAwIGFuZCA5LAohIGVsc2UgcmV0dXJucyBuaWwuIgohICAg KGFuZCAoPj0gY2hhcmFjdGVyID8wKQohICAgICAgICAoPD0gY2hhcmFjdGVyID85KSkpCiEgCiEg CiEgKGRlZnZhciBnZGJtaS1ibmYtc3RhdGUgJ2dkYm1pLWJuZi1vdXRwdXQKISAgICJDdXJyZW50 IEdEQi9NSSBvdXRwdXQgcGFyc2VyIHN0YXRlLiAgVGhlIHBhcnNlciBpcyBwbGFjZWQgaW4gYQoh IGRpZmZlcmVudCBzdGF0ZSB3aGVuIGFuIGluY29tcGxldGUgZGF0YSBzdGVhbSBpcyByZWNlaXZl ZCBmcm9tIEdEQi4KISBUaGlzIHZhcmlhYmxlIHdpbGwgcHJlc2VydmUgdGhlIHN0YXRlIHJlcXVp cmVkIHRvIHJlc3VtZSB0aGUgcGFyc2luZwohIHdoZW4gbW9yZSBkYXRhIGFycml2ZXMuIikKISAo bWFrZS12YXJpYWJsZS1idWZmZXItbG9jYWwgJ2dkYm1pLWJuZi1zdGF0ZSkKISAKISAoZGVmdmFy IGdkYm1pLWJuZi1vZmZzZXQgMAohICAgIk9mZnNldCBpbiBndWQtbWFya2VyLWFjYyBhdCB3aGlj aCB0aGUgcGFyc2VyIGlzIHJlYWRpbmcuCiEgVGhpcyBvZmZzZXQgaXMgdXNlZCB0byBiZSBhYmxl IHRvIHBhcnNlIHRoZSBHREIvTUkgbWVzc2FnZQohIGluLXBsYWNlLCB3aXRob3V0IHRoZSBuZWVk IG9mIGNvcHlpbmcgdGhlIHN0cmluZyBpbiBhIHRlbXBvcmFyeSBidWZmZXIKISBvciBkaXNjYXJk aW5nIHBhcnNlZCB0b2tlbnMgYnkgc3Vic3RyaW5naW5nIHRoZSBtZXNzYWdlLiIpCiEgKG1ha2Ut dmFyaWFibGUtYnVmZmVyLWxvY2FsICdnZGJtaS1ibmYtb2Zmc2V0KQohIAohIChkZWZ1biBnZGJt aS1ibmYtaW5pdCAoKQohICAgIkluaXRpYWxpemVzIHRoZSBHREIvTUkgbWVzc2FnZSBwYXJzZXIi CiEgICAoc2V0cSBnZGJtaS1ibmYtc3RhdGUgJ2dkYm1pLWJuZi1vdXRwdXQpCiEgICAoc2V0cSBn ZGJtaS1ibmYtb2Zmc2V0IDApCiEgICAoc2V0cSBndWQtbWFya2VyLWFjYyAiIikpCiEgCiEgCiEg KGRlZnVuIGdkYm1pLWJuZi1vdXRwdXQgKCkKISAgICJJbXBsZW1lbnRhdGlvbiBvZiB0aGUgZm9s bG93aW5nIEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlOgohIAohICAgb3V0cHV0ID09PgohICAg ICAgICAoIG91dC1vZi1iYW5kLXJlY29yZCApKiBbIHJlc3VsdC1yZWNvcmQgXSBnZGItcHJvbXB0 IgohIAohICAgICAoZ2RibWktYm5mLXNraXAtdW5yZWNvZ25pemVkKQohICAgICAod2hpbGUgKGdk Ym1pLWJuZi1vdXQtb2YtYmFuZC1yZWNvcmQpKQohICAgICAoZ2RibWktYm5mLXJlc3VsdC1yZWNv cmQpCiEgICAgIChnZGJtaS1ibmYtZ2RiLXByb21wdCkpCiEgCiEgCiEgKGRlZnVuIGdkYm1pLWJu Zi1za2lwLXVucmVjb2duaXplZCAoKQohICJVc2VkIGFzIGEgcHJvdGVjdGlvbiBtZWNoYW5pc20g aW4gY2FzZSBzb21ldGhpbmcgZ29lcyB3cm9uZyB3aGVuIHBhcnNpbmcKISBhIEdEQi9NSSByZXBs eSBtZXNzYWdlLiAgVGhpcyBmdW5jdGlvbiB3aWxsIHNraXAgY2hhcmFjdGVycyB1bnRpbCBpcyBl bmNvdW50ZXJzCiEgdGhlIGJlZ2lubmluZyBvZiBhIHZhbGlkIHJlY29yZC4iCiEgICAobGV0ICgo YWNjLWxlbmd0aCAobGVuZ3RoIGd1ZC1tYXJrZXItYWNjKSkKISAJKHByZWZpeC1vZmZzZXQgZ2Ri bWktYm5mLW9mZnNldCkKISAJKHByb21wdCAiKGdkYikgXG4iKSkKISAKISAgICAgKHdoaWxlIChh bmQgKDwgcHJlZml4LW9mZnNldCBhY2MtbGVuZ3RoKQohICAgICAgICAgICAgICAgICAoZ2RibWkt aXMtbnVtYmVyIChhcmVmIGd1ZC1tYXJrZXItYWNjIHByZWZpeC1vZmZzZXQpKSkKISAgICAgICAo c2V0cSBwcmVmaXgtb2Zmc2V0ICgxKyBwcmVmaXgtb2Zmc2V0KSkpCiEgCiEgICAgIChpZiAoYW5k ICg8IHByZWZpeC1vZmZzZXQgYWNjLWxlbmd0aCkKISAgICAgICAgICAgICAgKG5vdCAobWVtYmVy IChhcmVmIGd1ZC1tYXJrZXItYWNjIHByZWZpeC1vZmZzZXQpICcoP14gPyogPysgPz0gP34gP0Ag PyYpKSkKISAgICAgICAgICAgICAgKG5vdCAoZ2RibWktc2FtZS1zdGFydCBndWQtbWFya2VyLWFj YyBnZGJtaS1ibmYtb2Zmc2V0IHByb21wdCkpCiEgICAgICAgICAgICAgIChzdHJpbmctbWF0Y2gg IlxcKFteXiorPX5AJl0rXFwpIiBndWQtbWFya2VyLWFjYyBnZGJtaS1ibmYtb2Zmc2V0KSkKISAg ICAgICAgIChsZXQgKCh1bnJlY29nbml6ZWQtc3RyIChtYXRjaC1zdHJpbmcgMCBndWQtbWFya2Vy LWFjYykpKQohICAgICAgICAgICAoc2V0cSBnZGJtaS1ibmYtb2Zmc2V0IChtYXRjaC1lbmQgMCkp CiEgCSAgKGlmIGdkYm1pLWRlYnVnLW1vZGUgKG1lc3NhZ2UgImdkYm1pLWJuZi1za2lwLXVucmVj b2duaXplZDogJXMiIHVucmVjb2duaXplZC1zdHIpKQohICAgICAgICAgICAoZ2RiLXNoZWxsIHVu cmVjb2duaXplZC1zdHIpCiEgCSAgdCkpKSkKISAKISAKISAoZGVmdW4gZ2RibWktYm5mLWdkYi1w cm9tcHQgKCkKISAgICJJbXBsZW1lbnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nIEdEQi9NSSBvdXRw dXQgZ3JhbW1hciBydWxlOgohICAgZ2RiLXByb21wdCA9PT4KISAgICAgICAgJyhnZGIpJyBubAoh IAohICAgbmwgPT0+CiEgICAgICAgIENSIHwgQ1ItTEYiCiEgCiEgICAobGV0ICgocHJvbXB0ICIo Z2RiKSBcbiIpKQohICAgICAod2hlbiAoZ2RibWktc3RhcnQtd2l0aCBndWQtbWFya2VyLWFjYyBn ZGJtaS1ibmYtb2Zmc2V0IHByb21wdCkKISAgICAgICAoaWYgZ2RibWktZGVidWctbW9kZSAobWVz c2FnZSAiZ2RibWktYm5mLWdkYi1wcm9tcHQ6ICVzIiBwcm9tcHQpKQohICAgICAgIChnZGItZ2Ri IHByb21wdCkKISAgICAgICAoc2V0cSBnZGJtaS1ibmYtb2Zmc2V0ICgrIGdkYm1pLWJuZi1vZmZz ZXQgKGxlbmd0aCBwcm9tcHQpKSkKISAKISAgICAgICA7OyBSZXR1cm5zIG5vbi1uaWwgdG8gdGVs bCBndWQtZ2RibWktbWFya2VyLWZpbHRlciB3ZSd2ZSByZWFjaGVkCiEgICAgICAgOzsgdGhlIGVu ZCBvZiBhIEdEQiByZXBseSBtZXNzYWdlLgohICAgICAgIHQpKSkKISAKISAKISAoZGVmdW4gZ2Ri bWktYm5mLXJlc3VsdC1yZWNvcmQgKCkKISAgICJJbXBsZW1lbnRhdGlvbiBvZiB0aGUgZm9sbG93 aW5nIEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlOgohIAohICAgcmVzdWx0LXJlY29yZCA9PT4K ISAgICAgICAgWyB0b2tlbiBdICdeJyByZXN1bHQtY2xhc3MgKCAnLCcgcmVzdWx0ICkqIG5sCiEg CiEgICB0b2tlbiA9PT4KISAgICAgICAgYW55IHNlcXVlbmNlIG9mIGRpZ2l0cy4iCiEgCiEgICAo Z2RibWktYm5mLXJlc3VsdC1hbmQtYXN5bmMtcmVjb3JkLWltcGwpKQohIAohIAohIChkZWZ1biBn ZGJtaS1ibmYtb3V0LW9mLWJhbmQtcmVjb3JkICgpCiEgICAiSW1wbGVtZW50YXRpb24gb2YgdGhl IGZvbGxvd2luZyBHREIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZToKISAKISAgIG91dC1vZi1iYW5k LXJlY29yZCA9PT4KISAgICAgICAgYXN5bmMtcmVjb3JkIHwgc3RyZWFtLXJlY29yZCIKISAKISAg IChvciAoZ2RibWktYm5mLWFzeW5jLXJlY29yZCkKISAgICAgICAoZ2RibWktYm5mLXN0cmVhbS1y ZWNvcmQpKSkKISAKISAKISAoZGVmdW4gZ2RibWktYm5mLWFzeW5jLXJlY29yZCAoKQohICAgIklt cGxlbWVudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcgR0RCL01JIG91dHB1dCBncmFtbWFyIHJ1bGVz OgohIAohICAgYXN5bmMtcmVjb3JkID09PgohICAgICAgICBleGVjLWFzeW5jLW91dHB1dCB8IHN0 YXR1cy1hc3luYy1vdXRwdXQgfCBub3RpZnktYXN5bmMtb3V0cHV0CiEgCiEgICBleGVjLWFzeW5j LW91dHB1dCA9PT4KISAgICAgICAgWyB0b2tlbiBdICcqJyBhc3luYy1vdXRwdXQKISAKISAgIHN0 YXR1cy1hc3luYy1vdXRwdXQgPT0+CiEgICAgICAgIFsgdG9rZW4gXSAnKycgYXN5bmMtb3V0cHV0 CiEgCiEgICBub3RpZnktYXN5bmMtb3V0cHV0ID09PgohICAgICAgICBbIHRva2VuIF0gJz0nIGFz eW5jLW91dHB1dAohIAohICAgYXN5bmMtb3V0cHV0ID09PgohICAgICAgICBhc3luYy1jbGFzcyAo ICcsJyByZXN1bHQgKSogbmwiCiEgCiEgICAoZ2RibWktYm5mLXJlc3VsdC1hbmQtYXN5bmMtcmVj b3JkLWltcGwpKQohIAohIAohIChkZWZ1biBnZGJtaS1ibmYtc3RyZWFtLXJlY29yZCAoKQohICAg IkltcGxlbWVudCB0aGUgZm9sbG93aW5nIEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlOgohICAg c3RyZWFtLXJlY29yZCA9PT4KISAgICAgICAgY29uc29sZS1zdHJlYW0tb3V0cHV0IHwgdGFyZ2V0 LXN0cmVhbS1vdXRwdXQgfCBsb2ctc3RyZWFtLW91dHB1dAohIAohICAgY29uc29sZS1zdHJlYW0t b3V0cHV0ID09PgohICAgICAgICAnficgYy1zdHJpbmcKISAKISAgIHRhcmdldC1zdHJlYW0tb3V0 cHV0ID09PgohICAgICAgICAnQCcgYy1zdHJpbmcKISAKISAgIGxvZy1zdHJlYW0tb3V0cHV0ID09 PgohICAgICAgICAnJicgYy1zdHJpbmciCiEgICAod2hlbiAoPCBnZGJtaS1ibmYtb2Zmc2V0IChs ZW5ndGggZ3VkLW1hcmtlci1hY2MpKQohICAgICAoaWYgKGFuZCAobWVtYmVyIChhcmVmIGd1ZC1t YXJrZXItYWNjIGdkYm1pLWJuZi1vZmZzZXQpICcoP34gP0AgPyYpKQohICAgICAgICAgICAgICAo c3RyaW5nLW1hdGNoICJcXChbfkAmXVxcKVxcKFwiLio/XCJcXClcbiIgZ3VkLW1hcmtlci1hY2Mg Z2RibWktYm5mLW9mZnNldCkpCiEgICAgICAgICAobGV0ICgocHJlZml4IChtYXRjaC1zdHJpbmcg MSBndWQtbWFya2VyLWFjYykpCiEgICAgICAgICAgICAgICAoYy1zdHJpbmcgKG1hdGNoLXN0cmlu ZyAyIGd1ZC1tYXJrZXItYWNjKSkpCiEgCiEgICAgICAgICAgIChzZXRxIGdkYm1pLWJuZi1vZmZz ZXQgKG1hdGNoLWVuZCAwKSkKISAgICAgICAgICAgKGlmIGdkYm1pLWRlYnVnLW1vZGUgKG1lc3Nh Z2UgImdkYm1pLWJuZi1zdHJlYW0tcmVjb3JkOiAlcyIgKG1hdGNoLXN0cmluZyAwIGd1ZC1tYXJr ZXItYWNjKSkpCiEgCiEgICAgICAgICAgIChjb25kICgoc3RyaW5nLWVxdWFsIHByZWZpeCAifiIp CiEgICAgICAgICAgICAgICAgICAoZ2RibWktYm5mLWNvbnNvbGUtc3RyZWFtLW91dHB1dCBjLXN0 cmluZykpCiEgICAgICAgICAgICAgICAgICgoc3RyaW5nLWVxdWFsIHByZWZpeCAiQCIpCiEgICAg ICAgICAgICAgICAgICAoZ2RibWktYm5mLXRhcmdldC1zdHJlYW0tb3V0cHV0IGMtc3RyaW5nKSkK ISAgICAgICAgICAgICAgICAgKChzdHJpbmctZXF1YWwgcHJlZml4ICImIikKISAgICAgICAgICAg ICAgICAgIChnZGJtaS1ibmYtbG9nLXN0cmVhbS1vdXRwdXQgYy1zdHJpbmcpKSkKISAJICB0KSkp KQohIAohIChkZWZ1biBnZGJtaS1ibmYtY29uc29sZS1zdHJlYW0tb3V0cHV0IChjLXN0cmluZykK ISAgICJIYW5kbGVyIGZvciB0aGUgY29uc29sZS1zdHJlYW0tb3V0cHV0IEdEQi9NSSBvdXRwdXQg Z3JhbW1hciBydWxlIgohICAgKGdkYi1jb25zb2xlIGMtc3RyaW5nKSkKISAKISAoZGVmdW4gZ2Ri bWktYm5mLXRhcmdldC1zdHJlYW0tb3V0cHV0IChjLXN0cmluZykKISAgICJIYW5kbGVyIGZvciB0 aGUgdGFyZ2V0LXN0cmVhbS1vdXRwdXQgR0RCL01JIG91dHB1dCBncmFtbWFyIHJ1bGUiCiEgICA7 OyBOb3QgY3VycmVudGx5IHVzZWQuCiEgICApCiEgCiEgKGRlZnVuIGdkYm1pLWJuZi1sb2ctc3Ry ZWFtLW91dHB1dCAoYy1zdHJpbmcpCiEgICAiSGFuZGxlciBmb3IgdGhlIGxvZy1zdHJlYW0tb3V0 cHV0IEdEQi9NSSBvdXRwdXQgZ3JhbW1hciBydWxlIgohICAgOzsgU3VwcHJlc3MgIk5vIHJlZ2lz dGVycy4iICBHREIgNi44IGFuZCBlYXJsaWVyCiEgICA7OyBkdXBsaWNhdGVzIE1JIGVycm9yIG1l c3NhZ2Ugb24gaW50ZXJuYWwgc3RyZWFtLgohICAgOzsgRG9uJ3QgcHJpbnQgdG8gR1VEIGJ1ZmZl ci4KISAgIChpZiAobm90IChzdHJpbmctZXF1YWwgKHJlYWQgYy1zdHJpbmcpICJObyByZWdpc3Rl cnMuXG4iKSkKISAgICAgICAoZ2RiLWludGVybmFscyBjLXN0cmluZykpKQohIAohIAohIChkZWZj b25zdCBnZGJtaS1ibmYtcmVzdWx0LXN0YXRlLWNvbmZpZ3MKISAgICcoKCJeIiAuICgoImRvbmUi IC4gKGdkYi1kb25lIC4gcHJvZ3Jlc3NpdmUpKQohICAgICAgICAgICAgICgiZXJyb3IiIC4gKGdk Yi1lcnJvciAuIHByb2dyZXNzaXZlKSkKISAgICAgICAgICAgICAoInJ1bm5pbmciIC4gKGdkYi1z dGFydGluZyAuIGF0b21pYykpKSkKISAgICAgKCIqIiAuICgoInN0b3BwZWQiIC4gKGdkYi1zdG9w cGVkIC4gYXRvbWljKSkKISAgICAgICAgICAgICAoInJ1bm5pbmciIC4gKGdkYi1ydW5uaW5nIC4g YXRvbWljKSkpKQohICAgICAoIisiIC4gKCkpCiEgICAgICgiPSIgLiAoKCJ0aHJlYWQtY3JlYXRl ZCIgLiAoZ2RiLXRocmVhZC1jcmVhdGVkIC4gYXRvbWljKSkKISAgICAgICAgICAgICAoInRocmVh ZC1zZWxlY3RlZCIgLiAoZ2RiLXRocmVhZC1zZWxlY3RlZCAuIGF0b21pYykpCiEgICAgICAgICAg ICAgKCJ0aHJlYWQtZXhpc3RlZCIgLiAoZ2RiLWlnbm9yZWQtbm90aWZpY2F0aW9uIC4gYXRvbWlj KSkKISAgICAgICAgICAgICAoJ2RlZmF1bHQgLiAoZ2RiLWlnbm9yZWQtbm90aWZpY2F0aW9uIC4g YXRvbWljKSkpKSkKISAgICJUd28gZGltZW5zaW9uYWwgYWxpc3QsIG1hcHBpbmcgdGhlIHR5cGUg YW5kIGNsYXNzIG9mIG1lc3NhZ2UgdG8gYSBoYW5kbGVyIGZ1bmN0aW9uLgohIEhhbmRsZXIgZnVu Y3Rpb25zIGFyZSBhbGwgZmxhZ2dlZCBhcyBlaXRoZXIgJ3Byb2dyZXNzaXZlJyBvciAnYXRvbWlj Jy4gICdwcm9ncmVzc2l2ZScKISBoYW5kbGVycyBhcmUgY2FwYWJsZSBvZiBwYXJzaW5nIGluY29t cGxldGUgbWVzc2FnZXMuICBUaGV5IGNhbiBiZSBjYWxsZWQgc2V2ZXJhbCB0aW1lCiEgd2l0aCBu ZXcgZGF0YSBjaHVuayBhcyB0aGV5IGFycml2ZSBmcm9tIEdEQi4gICdwcm9ncmVzc2l2ZScgaGFu ZGxlciBtdXN0IGhhdmUgYW4gZXh0cmEKISBhcmd1bWVudCB0aGF0IGlzIHNldCB0byBhIG5vbi1u aWwgdmFsdWUgd2hlbiB0aGUgbWVzc2FnZSBpcyBjb21wbGV0ZS4KISAKISBJbXBsZW1lbnQgdGhl IGZvbGxvd2luZyBHREIvTUkgb3V0cHV0IGdyYW1tYXIgcnVsZToKISAgIHJlc3VsdC1jbGFzcyA9 PT4KISAgICAgICAgJ2RvbmUnIHwgJ3J1bm5pbmcnIHwgJ2Nvbm5lY3RlZCcgfCAnZXJyb3InIHwg J2V4aXQnCiEgCiEgICBhc3luYy1jbGFzcyA9PT4KISAgICAgICAgJ3N0b3BwZWQnIHwgb3RoZXJz ICh3aGVyZSBvdGhlcnMgd2lsbCBiZSBhZGRlZCBkZXBlbmRpbmcgb24gdGhlIG5lZWRzLS10aGlz IGlzIHN0aWxsIGluIGRldmVsb3BtZW50KS4iKQohIAohIChkZWZ1biBnZGJtaS1ibmYtcmVzdWx0 LWFuZC1hc3luYy1yZWNvcmQtaW1wbCAoKQohICAgIkNvbW1vbiBpbXBsZW1lbnRhdGlvbiBvZiB0 aGUgcmVzdWx0LXJlY29yZCBhbmQgYXN5bmMtcmVjb3JkIHJ1bGUuICBCb3RoIHJ1bGUgc2hhcmUK ISB0aGUgc2FtZSBzeW50YXguICBUaG9zZSByZWNvcmRzIG1heSBiZSB2ZXJ5IGxhcmdlIGluIHNp emUuICBGb3IgdGhhdCByZWFzb24sIHRoZSAncmVzdWx0JwohIHBhcnQgb2YgdGhlICByZWNvcmQg aXMgcGFyc2VkIGJ5IGdkYm1pLWJuZi1pbmNvbXBsZXRlLXJlY29yZC1yZXN1bHQsIHdoaWNoIHdp bGwga2VlcAohIHJlY2VpdmluZyBjaGFyYWN0ZXJzIGFzIHRoZXkgYXJyaXZlIGZyb20gR0RCIHVu dGlsIHRoZSByZWNvcmQgaXMgY29tcGxldGUuIgohICAgKGxldCAoKGFjYy1sZW5ndGggKGxlbmd0 aCBndWQtbWFya2VyLWFjYykpCiEgCShwcmVmaXgtb2Zmc2V0IGdkYm1pLWJuZi1vZmZzZXQpKQoh IAohICAgICAod2hpbGUgKGFuZCAoPCBwcmVmaXgtb2Zmc2V0IGFjYy1sZW5ndGgpCiEgICAgICAg ICAgICAgICAgIChnZGJtaS1pcy1udW1iZXIgKGFyZWYgZ3VkLW1hcmtlci1hY2MgcHJlZml4LW9m ZnNldCkpKQohICAgICAgIChzZXRxIHByZWZpeC1vZmZzZXQgKDErIHByZWZpeC1vZmZzZXQpKSkK ISAKISAgICAgKGlmIChhbmQgKDwgcHJlZml4LW9mZnNldCBhY2MtbGVuZ3RoKQohICAgICAgICAg ICAgICAobWVtYmVyIChhcmVmIGd1ZC1tYXJrZXItYWNjIHByZWZpeC1vZmZzZXQpICcoPyogPysg Pz0gP14pKQohICAgICAgICAgICAgICAoc3RyaW5nLW1hdGNoICJcXChbMC05XSpcXClcXChbKis9 Xl1cXClcXCguKz9cXClcXChbLFxuXVxcKSIgZ3VkLW1hcmtlci1hY2MgZ2RibWktYm5mLW9mZnNl dCkpCiEgCiEgICAgICAgICAobGV0ICgodG9rZW4gKG1hdGNoLXN0cmluZyAxIGd1ZC1tYXJrZXIt YWNjKSkKISAJICAgICAgKHByZWZpeCAobWF0Y2gtc3RyaW5nIDIgZ3VkLW1hcmtlci1hY2MpKQoh IAkgICAgICAoY2xhc3MgKG1hdGNoLXN0cmluZyAzIGd1ZC1tYXJrZXItYWNjKSkKISAJICAgICAg KGNvbXBsZXRlIChzdHJpbmctZXF1YWwgKG1hdGNoLXN0cmluZyA0IGd1ZC1tYXJrZXItYWNjKSAi XG4iKSkKISAJICAgICAgY2xhc3MtYWxpc3QKISAJICAgICAgY2xhc3MtY29tbWFuZCkKISAKISAg ICAgICAgICAgKHNldHEgZ2RibWktYm5mLW9mZnNldCAobWF0Y2gtZW5kIDApKQohIAkgIChpZiBn ZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJnZGJtaS1ibmYtcmVzdWx0LXJlY29yZDogJXMiICht YXRjaC1zdHJpbmcgMCBndWQtbWFya2VyLWFjYykpKQohIAohICAgICAgICAgICAoc2V0cSBjbGFz cy1hbGlzdCAoY2RyIChhc3NvYyBwcmVmaXggZ2RibWktYm5mLXJlc3VsdC1zdGF0ZS1jb25maWdz KSkpCiEgICAgICAgICAgIChzZXRxIGNsYXNzLWNvbW1hbmQgKGNkciAoYXNzb2MgY2xhc3MgY2xh c3MtYWxpc3QpKSkKISAgICAgICAgICAgKGlmIChudWxsIGNsYXNzLWNvbW1hbmQpCiEgICAgICAg ICAgICAgICAoc2V0cSBjbGFzcy1jb21tYW5kIChjZHIgKGFzc29jICdkZWZhdWx0IGNsYXNzLWFs aXN0KSkpKQohIAohICAgICAgICAgICAoaWYgY29tcGxldGUKISAgICAgICAgICAgICAgIChpZiBj bGFzcy1jb21tYW5kCiEgICAgICAgICAgICAgICAgICAgKGlmIChlcXVhbCAoY2RyIGNsYXNzLWNv bW1hbmQpICdwcm9ncmVzc2l2ZSkKISAgICAgICAgICAgICAgICAgICAgICAgKGZ1bmNhbGwgKGNh ciBjbGFzcy1jb21tYW5kKSB0b2tlbiAiIiBjb21wbGV0ZSkKISAgICAgICAgICAgICAgICAgICAg IChmdW5jYWxsIChjYXIgY2xhc3MtY29tbWFuZCkgdG9rZW4gIiIpKSkKISAgICAgICAgICAgICAo c2V0cSBnZGJtaS1ibmYtc3RhdGUgYChsYW1iZGEgKCkgKGdkYm1pLWJuZi1pbmNvbXBsZXRlLXJl Y29yZC1yZXN1bHQgLHRva2VuICcsY2xhc3MtY29tbWFuZCkpKQohICAgICAgICAgICAgIChmdW5j YWxsIGdkYm1pLWJuZi1zdGF0ZSkpCiEgCSAgdCkpKSkKISAKISAoZGVmdW4gZ2RibWktYm5mLWlu Y29tcGxldGUtcmVjb3JkLXJlc3VsdCAodG9rZW4gY2xhc3MtY29tbWFuZCkKISAgICJTdGF0ZSBv ZiB0aGUgcGFyc2VyIHVzZWQgdG8gcHJvZ3Jlc3NpdmVseSBwYXJzZSBhIHJlc3VsdC1yZWNvcmQg b3IgYXN5bmMtcmVjb3JkCiEgcnVsZSBmcm9tIGFuIGluY29tcGxldGUgZGF0YSBzdHJlYW0uICBU aGUgcGFyc2VyIHdpbGwgc3RheSBpbiB0aGlzIHN0YXRlIHVudGlsIHRoZSBlbmQKISBvZiB0aGUg Y3VycmVudCByZXN1bHQgb3IgYXN5bmMgcmVjb3JkIGlzIHJlYWNoZWQuIgohICAgKHdoZW4gKDwg Z2RibWktYm5mLW9mZnNldCAobGVuZ3RoIGd1ZC1tYXJrZXItYWNjKSkKISAgICAgOzsgU2VhcmNo IHRoZSBkYXRhIHN0cmVhbSBmb3IgdGhlIGVuZCBvZiB0aGUgY3VycmVudCByZWNvcmQ6CiEgICAg IChsZXQqICgobmV3bGluZS1wb3MgKHN0cmluZy1tYXRjaCAiXG4iIGd1ZC1tYXJrZXItYWNjIGdk Ym1pLWJuZi1vZmZzZXQpKQohIAkgICAoaXMtcHJvZ3Jlc3NpdmUgKGVxdWFsIChjZHIgY2xhc3Mt Y29tbWFuZCkgJ3Byb2dyZXNzaXZlKSkKISAJICAgKGlzLWNvbXBsZXRlIChub3QgKG51bGwgbmV3 bGluZS1wb3MpKSkKISAJICAgcmVzdWx0LXN0cikKISAKISAgICAgICA7OyBVcGRhdGUgdGhlIGdk Ym1pLWJuZi1vZmZzZXQgb25seSBpZiB0aGUgY3VycmVudCBjaHVuayBvZiBkYXRhIGNhbgohICAg ICAgIDs7IGJlIHByb2Nlc3NlZCBieSB0aGUgY2xhc3MtY29tbWFuZCBoYW5kbGVyOgohICAgICAg ICh3aGVuIChvciBpcy1jb21wbGV0ZSBpcy1wcm9ncmVzc2l2ZSkKISAJKHNldHEgcmVzdWx0LXN0 ciAoc3Vic3RyaW5nIGd1ZC1tYXJrZXItYWNjIGdkYm1pLWJuZi1vZmZzZXQgbmV3bGluZS1wb3Mp KQohIAkoc2V0cSBnZGJtaS1ibmYtb2Zmc2V0ICgrIDEgbmV3bGluZS1wb3MpKSkKISAKISAgICAg ICAoaWYgZ2RibWktZGVidWctbW9kZSAobWVzc2FnZSAiZ2RibWktYm5mLWluY29tcGxldGUtcmVj b3JkLXJlc3VsdDogJXMiIChzdWJzdHJpbmcgZ3VkLW1hcmtlci1hY2MgZ2RibWktYm5mLW9mZnNl dCBuZXdsaW5lLXBvcykpKQohIAohICAgICAgIDs7IFVwZGF0ZSB0aGUgcGFyc2luZyBzdGF0ZSBi ZWZvcmUgaW52b2tpbmcgdGhlIGhhbmRsZXIgaW4gY2xhc3MtY29tbWFuZAohICAgICAgIDs7IHRv IG1ha2Ugc3VyZSBpdCdzIG5vdCBsZWZ0IGluIGFuIGludmFsaWQgc3RhdGUgaWYgdGhlIGhhbmRs ZXIgd2FzCiEgICAgICAgOzsgdG8gZ2VuZXJhdGUgYW4gZXJyb3IuCiEgICAgICAgKGlmIGlzLWNv bXBsZXRlCiEgCSAgKHNldHEgZ2RibWktYm5mLXN0YXRlICdnZGJtaS1ibmYtb3V0cHV0KSkKISAK ISAgICAgICAoaWYgY2xhc3MtY29tbWFuZAohIAkgIChpZiBpcy1wcm9ncmVzc2l2ZQohIAkgICAg ICAoZnVuY2FsbCAoY2FyIGNsYXNzLWNvbW1hbmQpIHRva2VuIHJlc3VsdC1zdHIgaXMtY29tcGxl dGUpCiEgCSAgICAoaWYgaXMtY29tcGxldGUKISAJCShmdW5jYWxsIChjYXIgY2xhc3MtY29tbWFu ZCkgdG9rZW4gcmVzdWx0LXN0cikpKSkKISAKISAgICAgICAodW5sZXNzIGlzLWNvbXBsZXRlIDs7 IEluY29tcGxldGUgZ2RiIHJlc3BvbnNlOiBhYm9ydCB0aGUgcGFyc2luZyB1bnRpbCB3ZSByZWNl aXZlIG1vcmUgZGF0YS4KISAgICAgICAgIChpZiBnZGJtaS1kZWJ1Zy1tb2RlIChtZXNzYWdlICJn ZGJtaS1ibmYtaW5jb21wbGV0ZS1yZWNvcmQtcmVzdWx0LCBhYm9ydGluZzogaW5jb21wbGV0ZSBz dHJlYW0iKSkKISAgICAgICAgICh0aHJvdyAnZ2RibWktaW5jb21wbGV0ZS1zdHJlYW0gbmlsKSkK ISAKISAgICAgICBpcy1jb21wbGV0ZSkpKQohIAohIAohIDsgVGhlIGZvbGxvd2luZyBncmFtbWFy IHJ1bGVzIGFyZSBub3QgeWV0IGltcGxlbWVudGVkIGJ5IHRoaXMgR0RCTUktQk5GIHBhcnNlci4K ISA7IFRoZSBoYW5kbGluZyBvZiB0aG9zZSBydWxlcyBpcyBjdXJyZW50bHkgZG9uZSBieSB0aGUg aGFuZGxlcnMgcmVnaXN0ZXJlZAohIDsgaW4gZ2RibWktYm5mLXJlc3VsdC1zdGF0ZS1jb25maWdz CiEgOwohIDsgcmVzdWx0ID09PgohIDsgICAgICB2YXJpYWJsZSAiPSIgdmFsdWUKISA7CiEgOyB2 YXJpYWJsZSA9PT4KISA7ICAgICAgc3RyaW5nCiEgOwohIDsgdmFsdWUgPT0+CiEgOyAgICAgIGNv bnN0IHwgdHVwbGUgfCBsaXN0CiEgOwohIDsgY29uc3QgPT0+CiEgOyAgICAgIGMtc3RyaW5nCiEg OwohIDsgdHVwbGUgPT0+CiEgOyAgICAgICJ7fSIgfCAieyIgcmVzdWx0ICggIiwiIHJlc3VsdCAp KiAifSIKISA7CiEgOyBsaXN0ID09PgohIDsgICAgICAiW10iIHwgIlsiIHZhbHVlICggIiwiIHZh bHVlICkqICJdIiB8ICJbIiByZXN1bHQgKCAiLCIgcmVzdWx0ICkqICJdIgohIAogIAogIChkZWZ1 biBndWQtZ2RibWktbWFya2VyLWZpbHRlciAoc3RyaW5nKQogICAgIkZpbHRlciBHREIvTUkgb3V0 cHV0LiIKKioqKioqKioqKioqKioqCioqKiAxOTA3LDE5NTIgKioqKgogIAogICAgOzsgU3RhcnQg YWNjdW11bGF0aW5nIG91dHB1dCBmb3IgdGhlIEdVRCBidWZmZXIuCiAgICAoc2V0cSBnZGItZmls dGVyLW91dHB1dCAiIikKLSAgIChsZXQgKG91dHB1dC1yZWNvcmQtbGlzdCkKICAKISAgICAgOzsg UHJvY2VzcyBhbGwgdGhlIGNvbXBsZXRlIG1hcmtlcnMgaW4gdGhpcyBjaHVuay4KISAgICAgKGRv bGlzdCAoZ2RibWktcmVjb3JkIGdkYm1pLXJlY29yZC1saXN0KQohICAgICAgICh3aGlsZSAoc3Ry aW5nLW1hdGNoIChjZHIgZ2RibWktcmVjb3JkKSBndWQtbWFya2VyLWFjYykKISAJKHB1c2ggKGxp c3QgKG1hdGNoLWJlZ2lubmluZyAwKQohIAkJICAgIChjYXIgZ2RibWktcmVjb3JkKQohIAkJICAg IChtYXRjaC1zdHJpbmcgMSBndWQtbWFya2VyLWFjYykKISAJCSAgICAobWF0Y2gtc3RyaW5nIDIg Z3VkLW1hcmtlci1hY2MpCiEgCQkgICAgKG1hdGNoLWVuZCAwKSkKISAJICAgICAgb3V0cHV0LXJl Y29yZC1saXN0KQohIAkoc2V0cSBndWQtbWFya2VyLWFjYwohIAkgICAgICAoY29uY2F0IChzdWJz dHJpbmcgZ3VkLW1hcmtlci1hY2MgMCAobWF0Y2gtYmVnaW5uaW5nIDApKQohIAkJICAgICAgOzsg UGFkIHdpdGggc3BhY2VzIHRvIHByZXNlcnZlIHBvc2l0aW9uLgohIAkJICAgICAgKG1ha2Utc3Ry aW5nIChsZW5ndGggKG1hdGNoLXN0cmluZyAwIGd1ZC1tYXJrZXItYWNjKSkgMzIpCiEgCQkgICAg ICAoc3Vic3RyaW5nIGd1ZC1tYXJrZXItYWNjIChtYXRjaC1lbmQgMCkpKSkpKQohIAohICAgICAo c2V0cSBvdXRwdXQtcmVjb3JkLWxpc3QgKHNvcnQgb3V0cHV0LXJlY29yZC1saXN0ICdnZGItY2Fy PCkpCiEgCiEgICAgIChkb2xpc3QgKG91dHB1dC1yZWNvcmQgb3V0cHV0LXJlY29yZC1saXN0KQoh ICAgICAgIChsZXQgKChyZWNvcmQtdHlwZSAoY2FkciBvdXRwdXQtcmVjb3JkKSkKISAJICAgIChh cmcxIChudGggMiBvdXRwdXQtcmVjb3JkKSkKISAJICAgIChhcmcyIChudGggMyBvdXRwdXQtcmVj b3JkKSkpCiEgCShjb25kICgoZXEgcmVjb3JkLXR5cGUgJ2dkYi1lcnJvcikKISAJICAgICAgIChn ZGItZG9uZS1vci1lcnJvciBhcmcyIGFyZzEgJ2Vycm9yKSkKISAJICAgICAgKChlcSByZWNvcmQt dHlwZSAnZ2RiLWRvbmUpCiEgCSAgICAgICAoZ2RiLWRvbmUtb3ItZXJyb3IgYXJnMiBhcmcxICdk b25lKSkKISAJICAgICAgOzsgU3VwcHJlc3MgIk5vIHJlZ2lzdGVycy4iICBHREIgNi44IGFuZCBl YXJsaWVyCiEgCSAgICAgIDs7IGR1cGxpY2F0ZXMgTUkgZXJyb3IgbWVzc2FnZSBvbiBpbnRlcm5h bCBzdHJlYW0uCiEgCSAgICAgIDs7IERvbid0IHByaW50IHRvIEdVRCBidWZmZXIuCiEgCSAgICAg ICgobm90IChhbmQgKGVxIHJlY29yZC10eXBlICdnZGItaW50ZXJuYWxzKQohIAkJCSAoc3RyaW5n LWVxdWFsIChyZWFkIGFyZzEpICJObyByZWdpc3RlcnMuXG4iKSkpCiEgCSAgICAgICAoZnVuY2Fs bCByZWNvcmQtdHlwZSBhcmcxKSkpKSkKICAKISAgICAgKHNldHEgZ2RiLW91dHB1dC1zaW5rICd1 c2VyKQohICAgICA7OyBSZW1vdmUgcGFkZGluZy4KISAgICAgKHN0cmluZy1tYXRjaCAiXiAqIiBn dWQtbWFya2VyLWFjYykKISAgICAgKHNldHEgZ3VkLW1hcmtlci1hY2MgKHN1YnN0cmluZyBndWQt bWFya2VyLWFjYyAobWF0Y2gtZW5kIDApKSkKICAKISAgICAgZ2RiLWZpbHRlci1vdXRwdXQpKQog IAogIChkZWZ1biBnZGItZ2RiIChfb3V0cHV0LWZpZWxkKSkKICAKLS0tIDIyMTYsMjIzNSAtLS0t CiAgCiAgICA7OyBTdGFydCBhY2N1bXVsYXRpbmcgb3V0cHV0IGZvciB0aGUgR1VEIGJ1ZmZlci4K ICAgIChzZXRxIGdkYi1maWx0ZXItb3V0cHV0ICIiKQogIAohICAgKGxldCAoKGFjYy1sZW5ndGgg KGxlbmd0aCBndWQtbWFya2VyLWFjYykpKQohICAgICAoY2F0Y2ggJ2dkYm1pLWluY29tcGxldGUt c3RyZWFtCiEgICAgICAgKHdoaWxlIChhbmQgKDwgZ2RibWktYm5mLW9mZnNldCBhY2MtbGVuZ3Ro KQohIAkJICAoZnVuY2FsbCBnZGJtaS1ibmYtc3RhdGUpKSkpKQohIAohICAgKHdoZW4gKC89IGdk Ym1pLWJuZi1vZmZzZXQgMCkKISAgICAgKHNldHEgZ3VkLW1hcmtlci1hY2MgKHN1YnN0cmluZyBn dWQtbWFya2VyLWFjYyBnZGJtaS1ibmYtb2Zmc2V0KSkKISAgICAgKHNldHEgZ2RibWktYm5mLW9m ZnNldCAwKSkKICAKISAgICh3aGVuIChhbmQgZ2RibWktZGVidWctbW9kZSAoPiAobGVuZ3RoIGd1 ZC1tYXJrZXItYWNjKSAwKSkKISAgICAgKG1lc3NhZ2UgImd1ZC1nZGJtaS1tYXJrZXItZmlsdGVy LCB1bnBhcnNlZCBzdHJpbmc6ICVzIiBndWQtbWFya2VyLWFjYykpCiAgCiEgICBnZGItZmlsdGVy LW91dHB1dCkKICAKICAoZGVmdW4gZ2RiLWdkYiAoX291dHB1dC1maWVsZCkpCiAgCioqKioqKioq KioqKioqKgoqKiogMTk1NCwxOTY0ICoqKioKICAgIChzZXRxIGdkYi1maWx0ZXItb3V0cHV0CiAg ICAgICAgICAoY29uY2F0IG91dHB1dC1maWVsZCBnZGItZmlsdGVyLW91dHB1dCkpKQogIAohIChk ZWZ1biBnZGItaWdub3JlZC1ub3RpZmljYXRpb24gKF9vdXRwdXQtZmllbGQpKQogIAogIDs7IGdk Yi1pbnZhbGlkYXRlLXRocmVhZHMgaXMgZGVmaW5lZCB0byBhY2NlcHQgJ3VwZGF0ZS10aHJlYWRz IHNpZ25hbAohIChkZWZ1biBnZGItdGhyZWFkLWNyZWF0ZWQgKF9vdXRwdXQtZmllbGQpKQohIChk ZWZ1biBnZGItdGhyZWFkLWV4aXRlZCAob3V0cHV0LWZpZWxkKQogICAgIkhhbmRsZSA9dGhyZWFk LWV4aXRlZCBhc3luYyByZWNvcmQ6IHVuc2V0IGBnZGItdGhyZWFkLW51bWJlcicKICAgaWYgY3Vy cmVudCB0aHJlYWQgZXhpdGVkIGFuZCB1cGRhdGUgdGhyZWFkcyBsaXN0LiIKICAgIChsZXQqICgo dGhyZWFkLWlkIChiaW5kYXQtZ2V0LWZpZWxkIChnZGItanNvbi1zdHJpbmcgb3V0cHV0LWZpZWxk KSAnaWQpKSkKLS0tIDIyMzcsMjI0NyAtLS0tCiAgICAoc2V0cSBnZGItZmlsdGVyLW91dHB1dAog ICAgICAgICAgKGNvbmNhdCBvdXRwdXQtZmllbGQgZ2RiLWZpbHRlci1vdXRwdXQpKSkKICAKISAo ZGVmdW4gZ2RiLWlnbm9yZWQtbm90aWZpY2F0aW9uIChfdG9rZW4gX291dHB1dC1maWVsZCkpCiAg CiAgOzsgZ2RiLWludmFsaWRhdGUtdGhyZWFkcyBpcyBkZWZpbmVkIHRvIGFjY2VwdCAndXBkYXRl LXRocmVhZHMgc2lnbmFsCiEgKGRlZnVuIGdkYi10aHJlYWQtY3JlYXRlZCAoX3Rva2VuIF9vdXRw dXQtZmllbGQpKQohIChkZWZ1biBnZGItdGhyZWFkLWV4aXRlZCAoX3Rva2VuIG91dHB1dC1maWVs ZCkKICAgICJIYW5kbGUgPXRocmVhZC1leGl0ZWQgYXN5bmMgcmVjb3JkOiB1bnNldCBgZ2RiLXRo cmVhZC1udW1iZXInCiAgIGlmIGN1cnJlbnQgdGhyZWFkIGV4aXRlZCBhbmQgdXBkYXRlIHRocmVh ZHMgbGlzdC4iCiAgICAobGV0KiAoKHRocmVhZC1pZCAoYmluZGF0LWdldC1maWVsZCAoZ2RiLWpz b24tc3RyaW5nIG91dHB1dC1maWVsZCkgJ2lkKSkpCioqKioqKioqKioqKioqKgoqKiogMTk3MSwx OTc3ICoqKioKICAgICAgKGdkYi13YWl0LWZvci1wZW5kaW5nCiAgICAgICAoZ2RiLWVtaXQtc2ln bmFsIGdkYi1idWYtcHVibGlzaGVyICd1cGRhdGUtdGhyZWFkcykpKSkKICAKISAoZGVmdW4gZ2Ri LXRocmVhZC1zZWxlY3RlZCAob3V0cHV0LWZpZWxkKQogICAgIkhhbmRsZXIgZm9yID10aHJlYWQt c2VsZWN0ZWQgTUkgb3V0cHV0IHJlY29yZC4KICAKICBTZXRzIGBnZGItdGhyZWFkLW51bWJlcicg dG8gbmV3IGlkLiIKLS0tIDIyNTQsMjI2MCAtLS0tCiAgICAgIChnZGItd2FpdC1mb3ItcGVuZGlu ZwogICAgICAgKGdkYi1lbWl0LXNpZ25hbCBnZGItYnVmLXB1Ymxpc2hlciAndXBkYXRlLXRocmVh ZHMpKSkpCiAgCiEgKGRlZnVuIGdkYi10aHJlYWQtc2VsZWN0ZWQgKF90b2tlbiBvdXRwdXQtZmll bGQpCiAgICAiSGFuZGxlciBmb3IgPXRocmVhZC1zZWxlY3RlZCBNSSBvdXRwdXQgcmVjb3JkLgog IAogIFNldHMgYGdkYi10aHJlYWQtbnVtYmVyJyB0byBuZXcgaWQuIgoqKioqKioqKioqKioqKioK KioqIDE5ODgsMTk5NCAqKioqCiAgICAgIChnZGItd2FpdC1mb3ItcGVuZGluZwogICAgICAgKGdk Yi11cGRhdGUpKSkpCiAgCiEgKGRlZnVuIGdkYi1ydW5uaW5nIChvdXRwdXQtZmllbGQpCiAgICAo bGV0KiAoKHRocmVhZC1pZAogICAgICAgICAgICAoYmluZGF0LWdldC1maWVsZCAoZ2RiLWpzb24t c3RyaW5nIG91dHB1dC1maWVsZCkgJ3RocmVhZC1pZCkpKQogICAgICA7OyBXZSByZXNldCBnZGIt ZnJhbWUtbnVtYmVyIHRvIG5pbCBpZiBjdXJyZW50IHRocmVhZCBoYXMgZ29uZQotLS0gMjI3MSwy Mjc3IC0tLS0KICAgICAgKGdkYi13YWl0LWZvci1wZW5kaW5nCiAgICAgICAoZ2RiLXVwZGF0ZSkp KSkKICAKISAoZGVmdW4gZ2RiLXJ1bm5pbmcgKF90b2tlbiBvdXRwdXQtZmllbGQpCiAgICAobGV0 KiAoKHRocmVhZC1pZAogICAgICAgICAgICAoYmluZGF0LWdldC1maWVsZCAoZ2RiLWpzb24tc3Ry aW5nIG91dHB1dC1maWVsZCkgJ3RocmVhZC1pZCkpKQogICAgICA7OyBXZSByZXNldCBnZGItZnJh bWUtbnVtYmVyIHRvIG5pbCBpZiBjdXJyZW50IHRocmVhZCBoYXMgZ29uZQoqKioqKioqKioqKioq KioKKioqIDIwMDYsMjAxMiAqKioqCiAgICAoc2V0cSBnZGItYWN0aXZlLXByb2Nlc3MgdCkKICAg IChnZGItZW1pdC1zaWduYWwgZ2RiLWJ1Zi1wdWJsaXNoZXIgJ3VwZGF0ZS10aHJlYWRzKSkKICAK ISAoZGVmdW4gZ2RiLXN0YXJ0aW5nIChfb3V0cHV0LWZpZWxkKQogICAgOzsgQ0xJIGNvbW1hbmRz IGRvbid0IGVtaXQgXnJ1bm5pbmcgYXQgdGhlIG1vbWVudCBzbyB1c2UgZ2RiLXJ1bm5pbmcgdG9v LgogICAgKHNldHEgZ2RiLWluZmVyaW9yLXN0YXR1cyAicnVubmluZyIpCiAgICAoZ2RiLWZvcmNl LW1vZGUtbGluZS11cGRhdGUKLS0tIDIyODksMjI5NSAtLS0tCiAgICAoc2V0cSBnZGItYWN0aXZl LXByb2Nlc3MgdCkKICAgIChnZGItZW1pdC1zaWduYWwgZ2RiLWJ1Zi1wdWJsaXNoZXIgJ3VwZGF0 ZS10aHJlYWRzKSkKICAKISAoZGVmdW4gZ2RiLXN0YXJ0aW5nIChfb3V0cHV0LWZpZWxkIHJlc3Vs dCkKICAgIDs7IENMSSBjb21tYW5kcyBkb24ndCBlbWl0IF5ydW5uaW5nIGF0IHRoZSBtb21lbnQg c28gdXNlIGdkYi1ydW5uaW5nIHRvby4KICAgIChzZXRxIGdkYi1pbmZlcmlvci1zdGF0dXMgInJ1 bm5pbmciKQogICAgKGdkYi1mb3JjZS1tb2RlLWxpbmUtdXBkYXRlCioqKioqKioqKioqKioqKgoq KiogMjAyMCwyMDI2ICoqKioKICAKICA7OyAtYnJlYWstaW5zZXJ0IC10IGRpZG4ndCBnaXZlIGEg cmVhc29uIGJlZm9yZSBnZGIgNi45CiAgCiEgKGRlZnVuIGdkYi1zdG9wcGVkIChvdXRwdXQtZmll bGQpCiAgICAiR2l2ZW4gdGhlIGNvbnRlbnRzIG9mICpzdG9wcGVkIE1JIGFzeW5jIHJlY29yZCwg c2VsZWN0IG5ldwogIGN1cnJlbnQgdGhyZWFkIGFuZCB1cGRhdGUgR0RCIGJ1ZmZlcnMuIgogICAg OzsgUmVhc29uIGlzIGF2YWlsYWJsZSB3aXRoIHRhcmdldC1hc3luYyBvbmx5Ci0tLSAyMzAzLDIz MDkgLS0tLQogIAogIDs7IC1icmVhay1pbnNlcnQgLXQgZGlkbid0IGdpdmUgYSByZWFzb24gYmVm b3JlIGdkYiA2LjkKICAKISAoZGVmdW4gZ2RiLXN0b3BwZWQgKF90b2tlbiBvdXRwdXQtZmllbGQp CiAgICAiR2l2ZW4gdGhlIGNvbnRlbnRzIG9mICpzdG9wcGVkIE1JIGFzeW5jIHJlY29yZCwgc2Vs ZWN0IG5ldwogIGN1cnJlbnQgdGhyZWFkIGFuZCB1cGRhdGUgR0RCIGJ1ZmZlcnMuIgogICAgOzsg UmVhc29uIGlzIGF2YWlsYWJsZSB3aXRoIHRhcmdldC1hc3luYyBvbmx5CioqKioqKioqKioqKioq KgoqKiogMjEwNiwyMTEyICoqKioKICAgIChzZXRxIGdkYi1maWx0ZXItb3V0cHV0CiAgCShnZGIt Y29uY2F0LW91dHB1dCBnZGItZmlsdGVyLW91dHB1dCAocmVhZCBvdXRwdXQtZmllbGQpKSkpCiAg CiEgKGRlZnVuIGdkYi1kb25lLW9yLWVycm9yIChvdXRwdXQtZmllbGQgdG9rZW4tbnVtYmVyIHR5 cGUpCiAgICAoaWYgKHN0cmluZy1lcXVhbCB0b2tlbi1udW1iZXIgIiIpCiAgICAgICAgOzsgT3V0 cHV0IGZyb20gY29tbWFuZCBlbnRlcmVkIGJ5IHVzZXIKICAgICAgICAocHJvZ24KLS0tIDIzODks MjQwMSAtLS0tCiAgICAoc2V0cSBnZGItZmlsdGVyLW91dHB1dAogIAkoZ2RiLWNvbmNhdC1vdXRw dXQgZ2RiLWZpbHRlci1vdXRwdXQgKHJlYWQgb3V0cHV0LWZpZWxkKSkpKQogIAohIChkZWZ1biBn ZGItZG9uZSAodG9rZW4tbnVtYmVyIG91dHB1dC1maWVsZCBpcy1jb21wbGV0ZSkKISAgIChnZGIt ZG9uZS1vci1lcnJvciB0b2tlbi1udW1iZXIgJ2RvbmUgb3V0cHV0LWZpZWxkIGlzLWNvbXBsZXRl KSkKISAKISAoZGVmdW4gZ2RiLWVycm9yICh0b2tlbi1udW1iZXIgb3V0cHV0LWZpZWxkIGlzLWNv bXBsZXRlKQohICAgKGdkYi1kb25lLW9yLWVycm9yIHRva2VuLW51bWJlciAnZXJyb3Igb3V0cHV0 LWZpZWxkIGlzLWNvbXBsZXRlKSkKISAKISAoZGVmdW4gZ2RiLWRvbmUtb3ItZXJyb3IgKHRva2Vu LW51bWJlciB0eXBlIG91dHB1dC1maWVsZCBpcy1jb21wbGV0ZSkKICAgIChpZiAoc3RyaW5nLWVx dWFsIHRva2VuLW51bWJlciAiIikKICAgICAgICA7OyBPdXRwdXQgZnJvbSBjb21tYW5kIGVudGVy ZWQgYnkgdXNlcgogICAgICAgIChwcm9nbgoqKioqKioqKioqKioqKioKKioqIDIxMjIsMjEzNSAq KioqCiAgICAgIDs7IE91dHB1dCBmcm9tIGNvbW1hbmQgZnJvbSBmcm9udGVuZC4KICAgICAgKHNl dHEgZ2RiLW91dHB1dC1zaW5rICdlbWFjcykpCiAgCi0gICAoZ2RiLWNsZWFyLXBhcnRpYWwtb3V0 cHV0KQotIAogICAgOzsgVGhlIHByb2Nlc3MgbWF5IGFscmVhZHkgYmUgZGVhZCAoZS5nLiBDLWQg YXQgdGhlIGdkYiBwcm9tcHQpLgogICAgKGxldCogKChwcm9jIChnZXQtYnVmZmVyLXByb2Nlc3Mg Z3VkLWNvbWludC1idWZmZXIpKQogIAkgKG5vLXByb2MgKG9yIChudWxsIHByb2MpCiAgCQkgICAg ICAobWVtcSAocHJvY2Vzcy1zdGF0dXMgcHJvYykgJyhleGl0IHNpZ25hbCkpKSkpCiAgCiEgICAg ICh3aGVuIGdkYi1maXJzdC1kb25lLW9yLWVycm9yCiAgICAgICAgKHVubGVzcyAob3IgdG9rZW4t bnVtYmVyIGd1ZC1ydW5uaW5nIG5vLXByb2MpCiAgCShzZXRxIGdkYi1maWx0ZXItb3V0cHV0IChj b25jYXQgZ2RiLWZpbHRlci1vdXRwdXQgZ2RiLXByb21wdC1uYW1lKSkpCiAgICAgICAgKGdkYi11 cGRhdGUgbm8tcHJvYykKLS0tIDI0MTEsMjQyMiAtLS0tCiAgICAgIDs7IE91dHB1dCBmcm9tIGNv bW1hbmQgZnJvbSBmcm9udGVuZC4KICAgICAgKHNldHEgZ2RiLW91dHB1dC1zaW5rICdlbWFjcykp CiAgCiAgICA7OyBUaGUgcHJvY2VzcyBtYXkgYWxyZWFkeSBiZSBkZWFkIChlLmcuIEMtZCBhdCB0 aGUgZ2RiIHByb21wdCkuCiAgICAobGV0KiAoKHByb2MgKGdldC1idWZmZXItcHJvY2VzcyBndWQt Y29taW50LWJ1ZmZlcikpCiAgCSAobm8tcHJvYyAob3IgKG51bGwgcHJvYykKICAJCSAgICAgICht ZW1xIChwcm9jZXNzLXN0YXR1cyBwcm9jKSAnKGV4aXQgc2lnbmFsKSkpKSkKICAKISAgICAgKHdo ZW4gKGFuZCBpcy1jb21wbGV0ZSBnZGItZmlyc3QtZG9uZS1vci1lcnJvcikKICAgICAgICAodW5s ZXNzIChvciB0b2tlbi1udW1iZXIgZ3VkLXJ1bm5pbmcgbm8tcHJvYykKICAJKHNldHEgZ2RiLWZp bHRlci1vdXRwdXQgKGNvbmNhdCBnZGItZmlsdGVyLW91dHB1dCBnZGItcHJvbXB0LW5hbWUpKSkK ICAgICAgICAoZ2RiLXVwZGF0ZSBuby1wcm9jKQoqKioqKioqKioqKioqKioKKioqIDIxMzgsMjE1 MCAqKioqCiAgICAgIChzZXRxIGdkYi1maWx0ZXItb3V0cHV0CiAgCSAgKGdkYi1jb25jYXQtb3V0 cHV0IGdkYi1maWx0ZXItb3V0cHV0IG91dHB1dC1maWVsZCkpCiAgCiEgICAgICh3aGVuIHRva2Vu LW51bWJlcgogICAgICAgICh3aXRoLWN1cnJlbnQtYnVmZmVyCiAgCSAgKGdkYi1nZXQtYnVmZmVy LWNyZWF0ZSAnZ2RiLXBhcnRpYWwtb3V0cHV0LWJ1ZmZlcikKICAJKGZ1bmNhbGwKICAJIChjZHIg KGFzc29jIChzdHJpbmctdG8tbnVtYmVyIHRva2VuLW51bWJlcikgZ2RiLWhhbmRsZXItYWxpc3Qp KSkpCiAgICAgICAgKHNldHEgZ2RiLWhhbmRsZXItYWxpc3QKISAJICAgIChhc3NxLWRlbGV0ZS1h bGwgdG9rZW4tbnVtYmVyIGdkYi1oYW5kbGVyLWFsaXN0KSkpKSkKICAKICAoZGVmdW4gZ2RiLWNv bmNhdC1vdXRwdXQgKHNvLWZhciBuZXcpCiAgICAoY29uZAotLS0gMjQyNSwyNDQzIC0tLS0KICAg ICAgKHNldHEgZ2RiLWZpbHRlci1vdXRwdXQKICAJICAoZ2RiLWNvbmNhdC1vdXRwdXQgZ2RiLWZp bHRlci1vdXRwdXQgb3V0cHV0LWZpZWxkKSkKICAKISAgICAgOzsgV2UgYXJlIGRvbmUgY29uY2F0 ZW5hdGluZyB0byB0aGUgb3V0cHV0IHNpbmsuICBSZXN0b3JlIGl0IHRvIHVzZXIgc2luazoKISAg ICAgKHNldHEgZ2RiLW91dHB1dC1zaW5rICd1c2VyKQohIAohICAgICAod2hlbiAoYW5kIHRva2Vu LW51bWJlciBpcy1jb21wbGV0ZSkKICAgICAgICAod2l0aC1jdXJyZW50LWJ1ZmZlcgogIAkgIChn ZGItZ2V0LWJ1ZmZlci1jcmVhdGUgJ2dkYi1wYXJ0aWFsLW91dHB1dC1idWZmZXIpCiAgCShmdW5j YWxsCiAgCSAoY2RyIChhc3NvYyAoc3RyaW5nLXRvLW51bWJlciB0b2tlbi1udW1iZXIpIGdkYi1o YW5kbGVyLWFsaXN0KSkpKQogICAgICAgIChzZXRxIGdkYi1oYW5kbGVyLWFsaXN0CiEgICAgICAg ICAgICAgKGFzc3EtZGVsZXRlLWFsbCB0b2tlbi1udW1iZXIgZ2RiLWhhbmRsZXItYWxpc3QpKSkK ISAKISAgICh3aGVuIGlzLWNvbXBsZXRlCiEgICAgIChnZGItY2xlYXItcGFydGlhbC1vdXRwdXQp KSkpCiAgCiAgKGRlZnVuIGdkYi1jb25jYXQtb3V0cHV0IChzby1mYXIgbmV3KQogICAgKGNvbmQK --0015175cf87813586404d6d4a32f-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 11 13:15:22 2013 Received: (at 10580-done) by debbugs.gnu.org; 11 Mar 2013 17:15:22 +0000 Received: from localhost ([127.0.0.1]:46621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UF6Ji-0003IO-Jm for submit@debbugs.gnu.org; Mon, 11 Mar 2013 13:15:22 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:19357) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UF6Jd-0003I8-Aw for 10580-done@debbugs.gnu.org; Mon, 11 Mar 2013 13:15:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEvw4Xc4IeAQEEARo8IwULCzQSFA0LDSQTh38DCQa3Sw2JVYwShHgDklqBXY0PgzSBXoMTgUok X-IPAS-Result: Av8EABK/CFHO+KL9/2dsb2JhbABEvw4Xc4IeAQEEARo8IwULCzQSFA0LDSQTh38DCQa3Sw2JVYwShHgDklqBXY0PgzSBXoMTgUok X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="4218555" Received: from 206-248-162-253.dsl.teksavvy.com (HELO ceviche.home) ([206.248.162.253]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 Mar 2013 13:14:09 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7AE4E660E5; Mon, 11 Mar 2013 13:14:09 -0400 (EDT) From: Stefan Monnier To: Jean-Philippe Gravel Subject: Re: bug#10580: 24.0.92; gdb initialization takes more than one minute at 100 Message-ID: References: <87pq242gvz.fsf@gnu.org> Date: Mon, 11 Mar 2013 13:14:09 -0400 In-Reply-To: (Jean-Philippe Gravel's message of "Thu, 28 Feb 2013 22:31:03 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10580-done Cc: Chong Yidong , 10580-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) > My copyright assignment is finally complete. > While I was waiting for that, I found a problem with my patch. If you > use the gdb command "finish" to exit from a function, gdb replies with > a dump of the returned value (even though gdb-mi will not show it). > My previous patch was failing with a regexp overflow if the return > value was too big. This new patch will solve this problem. Thank you. I just installed it with the following changes (see patch below): - gdbmi-debug-mode is a defvar (such debug stuff doesn't deserve a defcustom). - Use the imperative "Return ..." rather than the present tense "Returns ..." in docstrings, as is the convention. I also integrated a few other suggestions from C-u M-x checkdoc-current-buffer (some of which affect code doesn't come from your patch, and there's more to fix). - Use the new defvar-local. - Fit within 80 columns. - Use lexical-binding for closures. and the following ChangeLog entry: 2013-03-11 Jean-Philippe Gravel * progmodes/gdb-mi.el: Speed up initialization (bug#10580). Use lexical-binding. Fix up docstring according to conventions. (gdbmi-debug-mode): New var. (gdbmi-start-with, gdbmi-same-start, gdbmi-is-number, gdbmi-bnf-init) (gdbmi-bnf-output, gdbmi-bnf-skip-unrecognized, gdbmi-bnf-gdb-prompt) (gdbmi-bnf-result-record, gdbmi-bnf-out-of-band-record) (gdbmi-bnf-async-record, gdbmi-bnf-stream-record) (gdbmi-bnf-console-stream-output, gdbmi-bnf-target-stream-output) (gdbmi-bnf-log-stream-output, gdbmi-bnf-result-and-async-record-impl) (gdbmi-bnf-incomplete-record-result): New functions. (gdb-car<): Remove function. (gdbmi-record-list): Remove variable. (gdbmi-bnf-state, gdbmi-bnf-offset): New vars. (gdbmi-bnf-result-state-configs): New const. (gud-gdbmi-marker-filter): Rewrite. (gdb-ignored-notification, gdb-thread-created, gdb-thread-exited) (gdb-thread-selected, gdb-running, gdb-starting, gdb-stopped): Add `token' argument. (gdb-done, gdb-error): New functions. (gdb-done-or-error): Add `is-complete' argument. Change arg order. Thank you very much for your help, Stefan --- lisp/progmodes/gdb-mi.el 2013-03-11 11:37:36.315869212 -0400 +++ lisp/progmodes/gdb-mi.el.new 2013-03-11 11:37:16.117759642 -0400 @@ -1,4 +1,4 @@ -;;; gdb-mi.el --- User Interface for running GDB +;;; gdb-mi.el --- User Interface for running GDB -*- lexical-binding: t -*- ;; Copyright (C) 2007-2013 Free Software Foundation, Inc. @@ -192,8 +192,8 @@ (defvar gdb-disassembly-position nil) (defvar gdb-location-alist nil - "Alist of breakpoint numbers and full filenames. Only used for files that -Emacs can't find.") + "Alist of breakpoint numbers and full filenames. +Only used for files that Emacs can't find.") (defvar gdb-active-process nil "GUD tooltips display variable values when t, and macro definitions otherwise.") (defvar gdb-error "Non-nil when GDB is reporting an error.") @@ -294,9 +294,7 @@ (funcall (cdr subscriber) signal))) (defvar gdb-buf-publisher '() - "Used to invalidate GDB buffers by emitting a signal in -`gdb-update'. - + "Used to invalidate GDB buffers by emitting a signal in `gdb-update'. Must be a list of pairs with cars being buffers and cdr's being valid signal handlers.") @@ -327,8 +325,7 @@ "When in non-stop mode, stopped threads can be examined while other threads continue to execute. -GDB session needs to be restarted for this setting to take -effect." +GDB session needs to be restarted for this setting to take effect." :type 'boolean :group 'gdb-non-stop :version "23.2") @@ -336,19 +333,18 @@ ;; TODO Some commands can't be called with --all (give a notice about ;; it in setting doc) (defcustom gdb-gud-control-all-threads t - "When enabled, GUD execution commands affect all threads when -in non-stop mode. Otherwise, only current thread is affected." + "When non-nil, GUD execution commands affect all threads when +in non-stop mode. Otherwise, only current thread is affected." :type 'boolean :group 'gdb-non-stop :version "23.2") (defcustom gdb-switch-reasons t - "List of stop reasons which cause Emacs to switch to the thread -which caused the stop. When t, switch to stopped thread no matter -what the reason was. When nil, never switch to stopped thread -automatically. + "List of stop reasons for which Emacs should switch thread. +When t, switch to stopped thread no matter what the reason was. +When nil, never switch to stopped thread automatically. -This setting is used in non-stop mode only. In all-stop mode, +This setting is used in non-stop mode only. In all-stop mode, Emacs always switches to the thread which caused the stop." ;; exited, exited-normally and exited-signaled are not ;; thread-specific stop reasons and therefore are not included in @@ -404,7 +400,7 @@ :link '(info-link "(gdb)GDB/MI Async Records")) (defcustom gdb-switch-when-another-stopped t - "When nil, Emacs won't switch to stopped thread if some other + "When nil, don't switch to stopped thread if some other stopped thread is already selected." :type 'boolean :group 'gdb-non-stop @@ -447,8 +443,7 @@ :version "23.2") (defcustom gdb-show-threads-by-default nil - "Show threads list buffer instead of breakpoints list by -default." + "Show threads list buffer instead of breakpoints list by default." :type 'boolean :group 'gdb-buffers :version "23.2") @@ -490,12 +485,12 @@ (defcustom gdb-create-source-file-list t "Non-nil means create a list of files from which the executable was built. - Set this to nil if the GUD buffer displays \"initializing...\" in the mode - line for a long time when starting, possibly because your executable was - built from a large number of files. This allows quicker initialization - but means that these files are not automatically enabled for debugging, - e.g., you won't be able to click in the fringe to set a breakpoint until - execution has already stopped there." +Set this to nil if the GUD buffer displays \"initializing...\" in the mode +line for a long time when starting, possibly because your executable was +built from a large number of files. This allows quicker initialization +but means that these files are not automatically enabled for debugging, +e.g., you won't be able to click in the fringe to set a breakpoint until +execution has already stopped there." :type 'boolean :group 'gdb :version "23.1") @@ -507,12 +502,8 @@ :group 'gdb :version "22.1") -(defcustom gdbmi-debug-mode nil - "When non-nil, all the messages sent or received from GDB/MI are printed in -the *Messages* buffer." - :type 'boolean - :group 'gud - :version "24.3") +(defvar gdbmi-debug-mode nil + "When non-nil, print the messages sent/received from GDB/MI in *Messages*.") (defun gdb-force-mode-line-update (status) (let ((buffer gud-comint-buffer)) @@ -577,7 +568,7 @@ (defmacro gdb-gud-context-call (cmd1 &optional cmd2 noall noarg) "`gud-call' wrapper which adds --thread/--all options between -CMD1 and CMD2. NOALL is the same as in `gdb-gud-context-command'. +CMD1 and CMD2. NOALL is the same as in `gdb-gud-context-command'. NOARG must be t when this macro is used outside `gud-def'" `(gud-call @@ -610,7 +601,7 @@ COMMAND-LINE is the shell command for starting the gdb session. It should be a string consisting of the name of the gdb -executable followed by command-line options. The command-line +executable followed by command line options. The command line options should include \"-i=mi\" to use gdb's MI text interface. Note that the old \"--annotate\" option is no longer supported. @@ -1263,7 +1254,7 @@ (cond ((> new previous) ;; Add new children to list. - (dotimes (dummy previous) + (dotimes (_ previous) (push (pop temp-var-list) var-list)) (dolist (child children) (let ((varchild @@ -1277,9 +1268,9 @@ (push varchild var-list)))) ;; Remove deleted children from list. ((< new previous) - (dotimes (dummy new) + (dotimes (_ new) (push (pop temp-var-list) var-list)) - (dotimes (dummy (- previous new)) + (dotimes (_ (- previous new)) (pop temp-var-list))))) (push var1 var-list)) (setq var1 (pop temp-var-list))) @@ -1511,7 +1502,7 @@ (gdb-input (concat "-inferior-tty-set " tty) 'ignore)))) -(defun gdb-inferior-io-sentinel (proc str) +(defun gdb-inferior-io-sentinel (proc _str) (when (eq (process-status proc) 'failed) ;; When the debugged process exits, Emacs gets an EIO error on ;; read from the pty, and stops listening to it. If the gdb @@ -1771,8 +1762,7 @@ "*")) (defun gdb-current-context-mode-name (mode) - "Add thread information to MODE which is to be used as -`mode-name'." + "Add thread information to MODE which is to be used as `mode-name'." (concat mode (if gdb-thread-number (format " [thread %s]" gdb-thread-number) @@ -1819,7 +1809,8 @@ ;; because we may need to update current gud-running value without ;; changing current thread (see gdb-running) (defun gdb-setq-thread-number (number) - "Only this function must be used to change `gdb-thread-number' + "Set `gdb-thread-number' to NUMBER. +Only this function must be used to change `gdb-thread-number' value to NUMBER, because `gud-running' and `gdb-frame-number' need to be updated appropriately when current thread changes." ;; GDB 6.8 and earlier always output thread-id="0" when stopping. @@ -1834,7 +1825,7 @@ Note that when `gdb-gud-control-all-threads' is t, `gud-running' cannot be reliably used to determine whether or not execution -control buttons should be shown in menu or toolbar. Use +control buttons should be shown in menu or toolbar. Use `gdb-running-threads-count' and `gdb-stopped-threads-count' instead. @@ -1886,7 +1877,7 @@ (defun gdbmi-start-with (str offset match) - "Returns non-nil if string STR starts with MATCH, else returns nil. + "Return non-nil if string STR starts with MATCH, else returns nil. OFFSET is the position in STR at which the comparison takes place." (let ((match-length (length match)) (str-length (- (length str) offset))) @@ -1894,7 +1885,7 @@ (string-equal match (substring str offset (+ offset match-length)))))) (defun gdbmi-same-start (str offset match) - "Returns non-nil if STR and MATCH are equal up to the end of either strings, else returns nil. + "Return non-nil iff STR and MATCH are equal up to the end of either strings. OFFSET is the position in STR at which the comparison takes place." (let* ((str-length (- (length str) offset)) (match-length (length match)) @@ -1904,28 +1895,26 @@ (substring match 0 compare-length))))) (defun gdbmi-is-number (character) -"Returns non-nil if CHARACTER is a numerical character between 0 and 9, -else returns nil." + "Return non-nil iff CHARACTER is a numerical character between 0 and 9." (and (>= character ?0) (<= character ?9))) -(defvar gdbmi-bnf-state 'gdbmi-bnf-output - "Current GDB/MI output parser state. The parser is placed in a -different state when an incomplete data steam is received from GDB. +(defvar-local gdbmi-bnf-state 'gdbmi-bnf-output + "Current GDB/MI output parser state. +The parser is placed in a different state when an incomplete data steam is +received from GDB. This variable will preserve the state required to resume the parsing when more data arrives.") -(make-variable-buffer-local 'gdbmi-bnf-state) -(defvar gdbmi-bnf-offset 0 - "Offset in gud-marker-acc at which the parser is reading. +(defvar-local gdbmi-bnf-offset 0 + "Offset in `gud-marker-acc' at which the parser is reading. This offset is used to be able to parse the GDB/MI message in-place, without the need of copying the string in a temporary buffer or discarding parsed tokens by substringing the message.") -(make-variable-buffer-local 'gdbmi-bnf-offset) (defun gdbmi-bnf-init () - "Initializes the GDB/MI message parser" + "Initialize the GDB/MI message parser." (setq gdbmi-bnf-state 'gdbmi-bnf-output) (setq gdbmi-bnf-offset 0) (setq gud-marker-acc "")) @@ -1937,16 +1926,16 @@ output ==> ( out-of-band-record )* [ result-record ] gdb-prompt" - (gdbmi-bnf-skip-unrecognized) - (while (gdbmi-bnf-out-of-band-record)) - (gdbmi-bnf-result-record) - (gdbmi-bnf-gdb-prompt)) + (gdbmi-bnf-skip-unrecognized) + (while (gdbmi-bnf-out-of-band-record)) + (gdbmi-bnf-result-record) + (gdbmi-bnf-gdb-prompt)) (defun gdbmi-bnf-skip-unrecognized () -"Used as a protection mechanism in case something goes wrong when parsing -a GDB/MI reply message. This function will skip characters until is encounters -the beginning of a valid record." + "Skip characters until is encounters the beginning of a valid record. +Used as a protection mechanism in case something goes wrong when parsing +a GDB/MI reply message." (let ((acc-length (length gud-marker-acc)) (prefix-offset gdbmi-bnf-offset) (prompt "(gdb) \n")) @@ -1956,12 +1945,15 @@ (setq prefix-offset (1+ prefix-offset))) (if (and (< prefix-offset acc-length) - (not (member (aref gud-marker-acc prefix-offset) '(?^ ?* ?+ ?= ?~ ?@ ?&))) + (not (memq (aref gud-marker-acc prefix-offset) + '(?^ ?* ?+ ?= ?~ ?@ ?&))) (not (gdbmi-same-start gud-marker-acc gdbmi-bnf-offset prompt)) - (string-match "\\([^^*+=~@&]+\\)" gud-marker-acc gdbmi-bnf-offset)) + (string-match "\\([^^*+=~@&]+\\)" gud-marker-acc + gdbmi-bnf-offset)) (let ((unrecognized-str (match-string 0 gud-marker-acc))) (setq gdbmi-bnf-offset (match-end 0)) - (if gdbmi-debug-mode (message "gdbmi-bnf-skip-unrecognized: %s" unrecognized-str)) + (if gdbmi-debug-mode + (message "gdbmi-bnf-skip-unrecognized: %s" unrecognized-str)) (gdb-shell unrecognized-str) t)))) @@ -2043,12 +2035,14 @@ '&' c-string" (when (< gdbmi-bnf-offset (length gud-marker-acc)) (if (and (member (aref gud-marker-acc gdbmi-bnf-offset) '(?~ ?@ ?&)) - (string-match "\\([~@&]\\)\\(\".*?\"\\)\n" gud-marker-acc gdbmi-bnf-offset)) + (string-match "\\([~@&]\\)\\(\".*?\"\\)\n" gud-marker-acc + gdbmi-bnf-offset)) (let ((prefix (match-string 1 gud-marker-acc)) (c-string (match-string 2 gud-marker-acc))) (setq gdbmi-bnf-offset (match-end 0)) - (if gdbmi-debug-mode (message "gdbmi-bnf-stream-record: %s" (match-string 0 gud-marker-acc))) + (if gdbmi-debug-mode (message "gdbmi-bnf-stream-record: %s" + (match-string 0 gud-marker-acc))) (cond ((string-equal prefix "~") (gdbmi-bnf-console-stream-output c-string)) @@ -2059,16 +2053,16 @@ t)))) (defun gdbmi-bnf-console-stream-output (c-string) - "Handler for the console-stream-output GDB/MI output grammar rule" + "Handler for the console-stream-output GDB/MI output grammar rule." (gdb-console c-string)) -(defun gdbmi-bnf-target-stream-output (c-string) - "Handler for the target-stream-output GDB/MI output grammar rule" +(defun gdbmi-bnf-target-stream-output (_c-string) + "Handler for the target-stream-output GDB/MI output grammar rule." ;; Not currently used. ) (defun gdbmi-bnf-log-stream-output (c-string) - "Handler for the log-stream-output GDB/MI output grammar rule" + "Handler for the log-stream-output GDB/MI output grammar rule." ;; Suppress "No registers." GDB 6.8 and earlier ;; duplicates MI error message on internal stream. ;; Don't print to GUD buffer. @@ -2087,23 +2081,26 @@ ("thread-selected" . (gdb-thread-selected . atomic)) ("thread-existed" . (gdb-ignored-notification . atomic)) ('default . (gdb-ignored-notification . atomic))))) - "Two dimensional alist, mapping the type and class of message to a handler function. -Handler functions are all flagged as either 'progressive' or 'atomic'. 'progressive' -handlers are capable of parsing incomplete messages. They can be called several time -with new data chunk as they arrive from GDB. 'progressive' handler must have an extra -argument that is set to a non-nil value when the message is complete. + "Alist of alists, mapping the type and class of message to a handler function. +Handler functions are all flagged as either `progressive' or `atomic'. +`progressive' handlers are capable of parsing incomplete messages. +They can be called several time with new data chunk as they arrive from GDB. +`progressive' handlers must have an extra argument that is set to a non-nil +value when the message is complete. Implement the following GDB/MI output grammar rule: result-class ==> 'done' | 'running' | 'connected' | 'error' | 'exit' async-class ==> - 'stopped' | others (where others will be added depending on the needs--this is still in development).") + 'stopped' | others (where others will be added depending on the needs + --this is still in development).") (defun gdbmi-bnf-result-and-async-record-impl () - "Common implementation of the result-record and async-record rule. Both rule share -the same syntax. Those records may be very large in size. For that reason, the 'result' -part of the record is parsed by gdbmi-bnf-incomplete-record-result, which will keep + "Common implementation of the result-record and async-record rule. +Both rules share the same syntax. Those records may be very large in size. +For that reason, the \"result\" part of the record is parsed by +`gdbmi-bnf-incomplete-record-result', which will keep receiving characters as they arrive from GDB until the record is complete." (let ((acc-length (length gud-marker-acc)) (prefix-offset gdbmi-bnf-offset)) @@ -2114,7 +2111,8 @@ (if (and (< prefix-offset acc-length) (member (aref gud-marker-acc prefix-offset) '(?* ?+ ?= ?^)) - (string-match "\\([0-9]*\\)\\([*+=^]\\)\\(.+?\\)\\([,\n]\\)" gud-marker-acc gdbmi-bnf-offset)) + (string-match "\\([0-9]*\\)\\([*+=^]\\)\\(.+?\\)\\([,\n]\\)" + gud-marker-acc gdbmi-bnf-offset)) (let ((token (match-string 1 gud-marker-acc)) (prefix (match-string 2 gud-marker-acc)) @@ -2124,9 +2122,11 @@ class-command) (setq gdbmi-bnf-offset (match-end 0)) - (if gdbmi-debug-mode (message "gdbmi-bnf-result-record: %s" (match-string 0 gud-marker-acc))) + (if gdbmi-debug-mode (message "gdbmi-bnf-result-record: %s" + (match-string 0 gud-marker-acc))) - (setq class-alist (cdr (assoc prefix gdbmi-bnf-result-state-configs))) + (setq class-alist + (cdr (assoc prefix gdbmi-bnf-result-state-configs))) (setq class-command (cdr (assoc class class-alist))) (if (null class-command) (setq class-command (cdr (assoc 'default class-alist)))) @@ -2136,14 +2136,16 @@ (if (equal (cdr class-command) 'progressive) (funcall (car class-command) token "" complete) (funcall (car class-command) token ""))) - (setq gdbmi-bnf-state `(lambda () (gdbmi-bnf-incomplete-record-result ,token ',class-command))) + (setq gdbmi-bnf-state + (lambda () + (gdbmi-bnf-incomplete-record-result token class-command))) (funcall gdbmi-bnf-state)) t)))) (defun gdbmi-bnf-incomplete-record-result (token class-command) "State of the parser used to progressively parse a result-record or async-record -rule from an incomplete data stream. The parser will stay in this state until the end -of the current result or async record is reached." +rule from an incomplete data stream. The parser will stay in this state until +the end of the current result or async record is reached." (when (< gdbmi-bnf-offset (length gud-marker-acc)) ;; Search the data stream for the end of the current record: (let* ((newline-pos (string-match "\n" gud-marker-acc gdbmi-bnf-offset)) @@ -2154,10 +2156,13 @@ ;; Update the gdbmi-bnf-offset only if the current chunk of data can ;; be processed by the class-command handler: (when (or is-complete is-progressive) - (setq result-str (substring gud-marker-acc gdbmi-bnf-offset newline-pos)) + (setq result-str + (substring gud-marker-acc gdbmi-bnf-offset newline-pos)) (setq gdbmi-bnf-offset (+ 1 newline-pos))) - (if gdbmi-debug-mode (message "gdbmi-bnf-incomplete-record-result: %s" (substring gud-marker-acc gdbmi-bnf-offset newline-pos))) + (if gdbmi-debug-mode + (message "gdbmi-bnf-incomplete-record-result: %s" + (substring gud-marker-acc gdbmi-bnf-offset newline-pos))) ;; Update the parsing state before invoking the handler in class-command ;; to make sure it's not left in an invalid state if the handler was @@ -2171,7 +2176,8 @@ (if is-complete (funcall (car class-command) token result-str)))) - (unless is-complete ;; Incomplete gdb response: abort the parsing until we receive more data. + (unless is-complete + ;; Incomplete gdb response: abort parsing until we receive more data. (if gdbmi-debug-mode (message "gdbmi-bnf-incomplete-record-result, aborting: incomplete stream")) (throw 'gdbmi-incomplete-stream nil)) @@ -2242,8 +2248,8 @@ ;; gdb-invalidate-threads is defined to accept 'update-threads signal (defun gdb-thread-created (_token _output-field)) (defun gdb-thread-exited (_token output-field) - "Handle =thread-exited async record: unset `gdb-thread-number' - if current thread exited and update threads list." + "Handle =thread-exited async record. +Unset `gdb-thread-number' if current thread exited and update threads list." (let* ((thread-id (bindat-get-field (gdb-json-string output-field) 'id))) (if (string= gdb-thread-number thread-id) (gdb-setq-thread-number nil)) @@ -2289,7 +2295,7 @@ (setq gdb-active-process t) (gdb-emit-signal gdb-buf-publisher 'update-threads)) -(defun gdb-starting (_output-field result) +(defun gdb-starting (_output-field _result) ;; CLI commands don't emit ^running at the moment so use gdb-running too. (setq gdb-inferior-status "running") (gdb-force-mode-line-update @@ -2462,8 +2468,8 @@ replaced with semicolons. If FIX-KEY is non-nil, strip all \"FIX-KEY=\" occurrences from -partial output. This is used to get rid of useless keys in lists -in MI messages, e.g.: [key=.., key=..]. -stack-list-frames and +partial output. This is used to get rid of useless keys in lists +in MI messages, e.g.: [key=.., key=..]. -stack-list-frames and -break-info are examples of MI commands which issue such responses. @@ -2630,16 +2636,16 @@ handler-name &optional signal-list) "Define a trigger TRIGGER-NAME which sends GDB-COMMAND and sets -HANDLER-NAME as its handler. HANDLER-NAME is bound to current +HANDLER-NAME as its handler. HANDLER-NAME is bound to current buffer with `gdb-bind-function-to-buffer'. If SIGNAL-LIST is non-nil, GDB-COMMAND is sent only when the -defined trigger is called with an argument from SIGNAL-LIST. It's +defined trigger is called with an argument from SIGNAL-LIST. It's not recommended to define triggers with empty SIGNAL-LIST. Normally triggers should respond at least to 'update signal. Normally the trigger defined by this command must be called from -the buffer where HANDLER-NAME must work. This should be done so +the buffer where HANDLER-NAME must work. This should be done so that buffer-local thread number may be used in GDB-COMMAND (by calling `gdb-current-context-command'). `gdb-bind-function-to-buffer' is used to achieve this, see @@ -2668,32 +2674,33 @@ Delete ((current-buffer) . TRIGGER-NAME) from `gdb-pending-triggers', erase current buffer and evaluate -CUSTOM-DEFUN. Then `gdb-update-buffer-name' is called. +CUSTOM-DEFUN. Then `gdb-update-buffer-name' is called. If NOPRESERVE is non-nil, window point is not restored after CUSTOM-DEFUN." `(defun ,handler-name () (gdb-delete-pending (cons (current-buffer) ',trigger-name)) - (let* ((buffer-read-only nil) - (window (get-buffer-window (current-buffer) 0)) - (start (window-start window)) - (p (window-point window))) + (let* ((inhibit-read-only t) + ,@(unless nopreserve + '((window (get-buffer-window (current-buffer) 0)) + (start (window-start window)) + (p (window-point window))))) (erase-buffer) (,custom-defun) (gdb-update-buffer-name) - ,(when (not nopreserve) - '(set-window-start window start) - '(set-window-point window p))))) + ,@(when (not nopreserve) + '((set-window-start window start) + (set-window-point window p)))))) (defmacro def-gdb-trigger-and-handler (trigger-name gdb-command handler-name custom-defun &optional signal-list) "Define trigger and handler. -TRIGGER-NAME trigger is defined to send GDB-COMMAND. See -`def-gdb-auto-update-trigger'. +TRIGGER-NAME trigger is defined to send GDB-COMMAND. +See `def-gdb-auto-update-trigger'. -HANDLER-NAME handler uses customization of CUSTOM-DEFUN. See -`def-gdb-auto-update-handler'." +HANDLER-NAME handler uses customization of CUSTOM-DEFUN. +See `def-gdb-auto-update-handler'." `(progn (def-gdb-auto-update-trigger ,trigger-name ,gdb-command @@ -3050,37 +3057,38 @@ gdb-running-threads-count gdb-stopped-threads-count)) - (gdb-table-add-row table - (list - (bindat-get-field thread 'id) - (concat - (if gdb-thread-buffer-verbose-names - (concat (bindat-get-field thread 'target-id) " ") "") - (bindat-get-field thread 'state) - ;; Include frame information for stopped threads - (if (not running) - (concat - " in " (bindat-get-field thread 'frame 'func) - (if gdb-thread-buffer-arguments - (concat - " (" - (let ((args (bindat-get-field thread 'frame 'args))) - (mapconcat - (lambda (arg) - (apply #'format "%s=%s" - (gdb-get-many-fields arg 'name 'value))) - args ",")) - ")") - "") - (if gdb-thread-buffer-locations - (gdb-frame-location (bindat-get-field thread 'frame)) "") - (if gdb-thread-buffer-addresses - (concat " at " (bindat-get-field thread 'frame 'addr)) "")) - ""))) - (list - 'gdb-thread thread - 'mouse-face 'highlight - 'help-echo "mouse-2, RET: select thread"))) + (gdb-table-add-row + table + (list + (bindat-get-field thread 'id) + (concat + (if gdb-thread-buffer-verbose-names + (concat (bindat-get-field thread 'target-id) " ") "") + (bindat-get-field thread 'state) + ;; Include frame information for stopped threads + (if (not running) + (concat + " in " (bindat-get-field thread 'frame 'func) + (if gdb-thread-buffer-arguments + (concat + " (" + (let ((args (bindat-get-field thread 'frame 'args))) + (mapconcat + (lambda (arg) + (apply #'format "%s=%s" + (gdb-get-many-fields arg 'name 'value))) + args ",")) + ")") + "") + (if gdb-thread-buffer-locations + (gdb-frame-location (bindat-get-field thread 'frame)) "") + (if gdb-thread-buffer-addresses + (concat " at " (bindat-get-field thread 'frame 'addr)) "")) + ""))) + (list + 'gdb-thread thread + 'mouse-face 'highlight + 'help-echo "mouse-2, RET: select thread"))) (when (string-equal gdb-thread-number (bindat-get-field thread 'id)) (setq marked-line (length gdb-threads-list)))) @@ -3096,8 +3104,8 @@ "Define a NAME command which will act upon thread on the current line. CUSTOM-DEFUN may use locally bound `thread' variable, which will -be the value of 'gdb-thread property of the current line. If -'gdb-thread is nil, error is signaled." +be the value of 'gdb-thread property of the current line. +If `gdb-thread' is nil, error is signaled." `(defun ,name (&optional event) ,(when doc doc) (interactive (list last-input-event)) @@ -3246,7 +3254,7 @@ (defun gdb-memory-column-width (size format) "Return length of string with memory unit of SIZE in FORMAT. -SIZE is in bytes, as in `gdb-memory-unit'. FORMAT is a string as +SIZE is in bytes, as in `gdb-memory-unit'. FORMAT is a string as in `gdb-memory-format'." (let ((format-base (cdr (assoc format '(("x" . 16) @@ -3748,8 +3756,7 @@ (error "Not recognized as break/watchpoint line"))))) (defun gdb-goto-breakpoint (&optional event) - "Go to the location of breakpoint at current line of -breakpoints buffer." + "Go to the location of breakpoint at current line of breakpoints buffer." (interactive (list last-input-event)) (if event (posn-set-point (event-end event))) ;; Hack to stop gdb-goto-breakpoint displaying in GUD buffer. @@ -4133,7 +4140,7 @@ (defun gdb-get-source-file-list () "Create list of source files for current GDB session. -If buffers already exist for any of these files, gud-minor-mode +If buffers already exist for any of these files, `gud-minor-mode' is set in them." (goto-char (point-min)) (while (re-search-forward gdb-source-file-regexp nil t) @@ -4144,8 +4151,8 @@ (gdb-init-buffer))))) (defun gdb-get-main-selected-frame () - "Trigger for `gdb-frame-handler' which uses main current -thread. Called from `gdb-update'." + "Trigger for `gdb-frame-handler' which uses main current thread. +Called from `gdb-update'." (if (not (gdb-pending-p 'gdb-get-main-selected-frame)) (progn (gdb-input (gdb-current-context-command "-stack-info-frame") @@ -4153,7 +4160,7 @@ (gdb-add-pending 'gdb-get-main-selected-frame)))) (defun gdb-frame-handler () - "Sets `gdb-selected-frame' and `gdb-selected-file' to show + "Set `gdb-selected-frame' and `gdb-selected-file' to show overlay arrow in source buffer." (gdb-delete-pending 'gdb-get-main-selected-frame) (let ((frame (bindat-get-field (gdb-json-partial-output) 'frame))) @@ -4214,8 +4221,8 @@ (defun gdb-preempt-existing-or-display-buffer (buf &optional split-horizontal) "Find window displaying a buffer with the same -`gdb-buffer-type' as BUF and show BUF there. If no such window -exists, just call `gdb-display-buffer' for BUF. If the window +`gdb-buffer-type' as BUF and show BUF there. If no such window +exists, just call `gdb-display-buffer' for BUF. If the window found is already dedicated, split window according to SPLIT-HORIZONTAL and show BUF in the new window." (if buf @@ -4603,8 +4610,7 @@ (gud-gdb-fetch-lines-break (length context)) (gud-gdb-fetched-lines nil) ;; This filter dumps output lines to `gud-gdb-fetched-lines'. - (gud-marker-filter #'gud-gdbmi-fetch-lines-filter) - complete-list) + (gud-marker-filter #'gud-gdbmi-fetch-lines-filter)) (with-current-buffer (gdb-get-buffer 'gdb-partial-output-buffer) (gdb-input (concat "complete " context command) (lambda () (setq gud-gdb-fetch-lines-in-progress nil))) From unknown Fri Jun 20 07:15:46 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 09 Apr 2013 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator