From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Revilak Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols Date: Sun, 24 Jan 2010 22:16:59 -0500 Message-ID: <20100125031659.GB984@srevilak.net> References: <20100117142534.GB372@srevilak.net> <19283.35226.712794.811198@totara.tehura.co.nz> <20100118155010.GA402@srevilak.net> <19284.58646.218954.708076@totara.tehura.co.nz> <20100119002604.GC744@srevilak.net> <19285.32978.732406.38527@totara.tehura.co.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" X-Trace: ger.gmane.org 1264391122 28696 80.91.229.12 (25 Jan 2010 03:45:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2010 03:45:22 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: Nick Roberts Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 25 04:45:14 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NZFpx-0006mX-5B for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Jan 2010 04:45:14 +0100 Original-Received: from localhost ([127.0.0.1]:38762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZFpb-0008SS-2r for geb-bug-gnu-emacs@m.gmane.org; Sun, 24 Jan 2010 22:41:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZFpW-0008SE-Aq for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2010 22:41:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZFpQ-0008RP-1U for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2010 22:41:32 -0500 Original-Received: from [199.232.76.173] (port=35563 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZFpP-0008RM-SJ for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2010 22:41:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55126) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZFp2-00067w-37 for bug-gnu-emacs@gnu.org; Sun, 24 Jan 2010 22:41:27 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NZFSj-0003uz-W1; Sun, 24 Jan 2010 22:18:02 -0500 X-Loop: bug-gnu-emacs@gnu.org Resent-From: Steve Revilak Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Jan 2010 03:18:01 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5404 X-Emacs-PR-Package: emacs,ns X-Emacs-PR-Keywords: Original-Received: via spool by submit@debbugs.gnu.org id=B.126438943415051 (code B ref -1); Mon, 25 Jan 2010 03:18:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 25 Jan 2010 03:17:14 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NZFRx-0003ui-Mw for submit@debbugs.gnu.org; Sun, 24 Jan 2010 22:17:14 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NZFRv-0003ub-Ld for submit@debbugs.gnu.org; Sun, 24 Jan 2010 22:17:12 -0500 Original-Received: from mx10.gnu.org ([199.232.76.166]:38963) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NZFRs-0001Ra-7S for emacs-pretest-bug@gnu.org; Sun, 24 Jan 2010 22:17:08 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NZFRq-00048P-D1 for emacs-pretest-bug@gnu.org; Sun, 24 Jan 2010 22:17:08 -0500 Original-Received: from mail8.sea5.speakeasy.net ([69.17.117.10]:35199) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZFRp-00047u-OY for emacs-pretest-bug@gnu.org; Sun, 24 Jan 2010 22:17:06 -0500 Original-Received: (qmail 16486 invoked from network); 25 Jan 2010 03:17:03 -0000 Original-Received: from pool-71-184-218-95.bstnma.fios.verizon.net (HELO srevilak.net) (srevilak@[71.184.218.95]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Jan 2010 03:17:02 -0000 Content-Disposition: inline In-Reply-To: <19285.32978.732406.38527@totara.tehura.co.nz> User-Agent: Mutt/1.5.19 (2009-01-05) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.6 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list X-Spam-Score: -6.6 (------) Resent-Date: Sun, 24 Jan 2010 22:18:01 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:34693 gmane.emacs.pretest.bugs:25409 Archived-At: --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable >From: Nick Roberts >I think the terminal settings in the GUD buffer must be different for rece= nt >Macs. > >Try: > >(gdb) shell stty -onlcr > >(assuming "shell stty -a" gives onlcr). > >Emacs doesn't expect the extra ^M characters and so it fails to parse the >output correctly. If modifying the terminal doesn't work (but I think it >should), you could try changing gud-gdb-marker-regexp and >gud-gdb-marker-filter to look for ^M\n instead of just \n. Nick, I had the chance to try your suggestions with onlcr/-onlcr. I wanted to see how M-x gdb (and M-x gud-gdb) apply that terminal setting in 23.1.91; I also wanted to compare this with Emacs 22.3. At the end of this message is an outline of the scenarios I've tried. I'll summarize the high points: - Emacs 23 runs gdb with "onlcr". Emacs 22 also used onlcr. (Emacs 22 did not exhibit the hanging or ^M behavior.) - In M-x gdb, changing onlcr to -onlcr prevents the hanging, but *only* if you make the change the terminal settings after gdb starts the target program. - The hanging in M-x gdb does NOT occur with M-x gud-gdb - with M-x gud-gdb, "shell stty -onlcr" makes the ^M's go away. - Looking through the code called by gud-gdb-complete-command, Emacs 22 and Emacs 23 are practically identical. In particular,=20 gud-gdb-marker-regexp and gud-gdb-marker-filter are the same. I'd like to figure out why M-x gdb and M-x gud-gdb behave differently, but I haven't gotten that far yet. I know that Emacs 23 merged the GNUStep and MacOS code together (into the nextstep port). Could the behavior I'm seeing be the result of something further down in the nextstep code? I've tried to keep the outline terse. If there are any points I should clarify, please let me know. Thanks again for all your guidance. If you have any suggestions for where to look next, please let me know. Steve =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Emacs 23.1.91 - Emacs -Q -nw ~/foo.c - M-x gdb RET Run gdb (like this): gdb --annotate=3D3 foo - At first (gdb) prompt, run "shell stty -a". stty output shows "onlcr". - Run "shell stty -onlcr". Afterwards, "shell stty -a" still shows "onlcr" (and not "-onlcr"). stty did NOT toggle the onlcr setting. - Type "b add_". This hangs, and has to be cancelled with C-g. - Type "b main RET", then "run RET". GDB runs target program, stops at breakpoint in main. - Type "b add_". Still hangs, and has to be cancelled with C-g. =20 - type "shell stty -onlcr". This does something interesting. Figure 1 shows the "foo.c" buffer before I type "shell stty -onlcr". ---- Figure 1 --------------------------------------------------- #include static int add_one(int x) { return (x + 1); } int main(void) { =3D>int y =3D add_one(3); printf("%d\n", y); return 0; } ------------------------------------------------------------------ - after typing "shell stty -onlcr", the appearance of the foo.c buffer changes to Figure 2. The code shifts two spaces to the right, and there is a `B' in column zero, to show where the breakpoint is set. ------- Figure 2 ------------------------------------------------- #include static int add_one(int x) { return (x + 1); } int main(void) { B =3D>int y =3D add_one(3); printf("%d\n", y); return 0; } ------------------------------------------------------------------ - type "shell stty -a". This time "onlcr" has changed to "-onlcr" - "b add_" does not hang. It produces a list of completions (and no ^M's :) OBSERVATION: before starting the target program, stty changes don't seem to take effect. After the target program starts running, stty changes do take effect. After "shell stty -onlcr", gud-gdb-complete-command does not hang, and there are no ctrl ^M's. This is at least a workaround. Within the *gud-PROGRAM* buffer, run "shell stty -onlcr" after the target program starts running, and don't try to use symbol completion before the target program starts. * Emacs 23.1.91 and M-x gud-gdb M-x gud-gdb has an interesting variant on the above behavior. - Emacs -nw -Q ~/foo.c - M-x gud-gdb RET Run gud-gdb (like this): gdb --fullname foo - At first (gdb) prompt, "shell stty -a" shows "-onlcr". This is the opposite behavior as M-x gdb - "b add_" produces a list of completions. It does not hang. There are no ^M's in the completion. - type "b main RET" then "run RET". - gdb starts running target program, and stops at first breakpoint. - "shell stty -a" shows "onlcr". Starting the target program flipped -onlcr to onlcr. =20 - "b add_" does not hang, but each completion is suffixed with ^M (a behavior we discussed with the 23.1.90 release). - "shell stty -onlcr" changes onlcr back to "-onlcr" - "b add_" produces a correct list of completions. OBSERVATION: I also see another workaround. After gdb starts the program, "shell stty -onlcr" makes ^M go away. * Comparing with Emacs 22.3 I tried this experiment with Emacs 22.3. In Emacs 22.3, gud-gdb-complete-command does not hang, and completions are not suffixed with ^M. I simply wanted to see what terminal settings M-x gdb used in the older version. - Emacs-22.3 -Q -nw ~/foo.c - M-x gdb RET Run gdb (like this): gdb --annotate=3D3 foo - At first (gdb) prompt "shell stty -a" shows "onlcr" in Emacs-22.3. - type "b main RET". Then "run RET" - when the breakpoint is hit, buffer "foo.c" looks like Figure 2. "shell stty -a" still shows "onlcr". OBSERVATION: Both Emacs-22.3 and 23.1.91 use "onlcr" in terminal settings. * Comparing gud.el Between Emacs 22.3 and Emacs 23.1.91 I spent some time using M-x compare-buffers to look at the differences between gud.el in Emacs 22.3 and Emacs 23.1.91. There are NO differences in the following: - gud-gdb-complete-command - gud-gdb-run-command-fetch-lines - gud-gdb-fetch-lines-filter - gud-gdb-marker-regexp - gud-gdb-marker-filter There is a small difference in gud-basic-call, but it looks like nothing more than a change to eliminate "Warning: `save-excursion' defeated by `set-buffer'". =20 These symbols seem to cover the major steps in gud-gdb-complete-command. --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (Darwin) iEYEARECAAYFAktdDSsACgkQX7YJI4BuyDRWBACg5ZYneK5KGzfcXKVTuWyn5KnB hzQAoIvM4XRuDgWnTJykdiRcfYkGZWG7 =VtDa -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F--