bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 13586 bytes --]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list,
and to the gnu.emacs.bug news group.

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':

I'd like to report a problem with M-x gdb in the Nextstep port of
emacs 23.1.91.  When gud mode is started with M-x gdb, tab completion
of symbols (i.e., gud-gdb-complete-command) causes emacs to hang.

The release announcement for emacs 23.1.91 noted a major change in M-x
gdb (<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg01109.html>)
and this seems to be new behavior in 23.1.91.


Steps To Reproduce
------------------

  1) Start with foo.c

---------------------------------
#include <stdio.h>

static int add_one(int x) {
   return (x + 1);
}

int main(void) {
   int y = add_one(3);
   printf("%d\n", y);
   return 0;
}
---------------------------------

  2) Compile foo.c

     $ make CFLAGS="-g -Wall" foo  
     cc -g -Wall    foo.c   -o foo

  3) Start emacs with the command line

     /Applications/Emacs.app/Contents/MacOS/Emacs -Q -nw foo.c

     Above, "-nw" isn't necessary for reproducing this behavior.  -nw
     just makes it easier to capture what emacs is displaying.

  4) Type M-x gdb RET

     Emacs responds with "Run gdb (like this): gdb --annotate=3 foo".

     Press RET to accept the gdb command line.

  5) Emacs creates a *gud-foo* buffer, whose initial contents are

---------------------------------
Current directory is ~/
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries .. done
(gdb) 
---------------------------------

  6) At the (gdb) prompt, type "b add_", then TAB

  7) After pressing TAB, emacs becomes unresponsive.

     Emacs stays unresponsive until Ctrl-G is pressed.


Observations from edebug
------------------------

I've used M-x edebug-defun to instrument different functions in
gud.el, so that I could step through them with emacs debugger.  

Emacs seems to hang when evaluating the expression

   (get-buffer-process gud-comint-buffer)

in line 981 of gud.el.  This line is part of defun
gud-gdb-run-command-fetch-lines.


Observations from gdb
---------------------

While emacs was hung (i.e., after completing step 7, above), I
attached a debugger to emacs.  Here is a backtrace:

(0:0)spud:srevilak$ gdb /Applications/Emacs.app/Contents/MacOS/Emacs
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries .... done

(gdb) attach 606
Attaching to program: `/Applications/Emacs.app/Contents/MacOS/Emacs', process 606.
Reading symbols for shared libraries ................................................................... done
0x9001f488 in select ()
(gdb) info threads
* 1 process 606 thread 0xd03  0x9001f488 in select ()

(gdb) bt
#0  0x9001f488 in select ()
#1  0x0015a2d8 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=0, do_display=0, wait_for_cell=41944074, wait_proc=0xa8f320, just_wait_proc=0) at process.c:4941
#2  0x0015c00c in Faccept_process_output (process=11072293, seconds=4, millisec=-1073750304, just_this_one=41944074) at process.c:4323
#3  0x00112eac in Ffuncall (nargs=4, args=0xbfffe250) at eval.c:3025
#4  0x001505bc in Fbyte_code (bytestr=48, vector=-1073749248, maxdepth=40) at bytecode.c:679
#5  0x00112a5c in funcall_lambda (fun=10653413, nargs=3, arg_vector=0xbfffe504) at eval.c:3202
#6  0x00112ffc in Ffuncall (nargs=4, args=0x48c17ca) at eval.c:3072
#7  0x001505bc in Fbyte_code (bytestr=48, vector=-1073748736, maxdepth=20) at bytecode.c:679
#8  0x00112a5c in funcall_lambda (fun=10652229, nargs=0, arg_vector=0xbfffe72c) at eval.c:3202
#9  0x00112ffc in Ffuncall (nargs=4, args=0x48c176a) at eval.c:3072
#10 0x00113b90 in apply1 (fn=76289898, arg=3906012) at eval.c:2756
#11 0x0010ddbc in Fcall_interactively (function=76289898, record_flag=41944074, keys=22028253) at callint.c:396
#12 0x00112e88 in Ffuncall (nargs=4, args=0xbfffe91c) at eval.c:3021
#13 0x00113188 in call3 (fn=4, arg1=-1073750304, arg2=0, arg3=0) at eval.c:2841
#14 0x000ab524 in command_loop_1 () at keyboard.c:1904
#15 0x0010ff68 in internal_condition_case (bfun=0xaa160 <command_loop_1>, handlers=41978570, hfun=0xa1fd0 <cmd_error>) at eval.c:1490
#16 0x0009a8a0 in command_loop_2 () at keyboard.c:1360
#17 0x0010fdf0 in internal_catch (tag=4, func=0x9a860 <command_loop_2>, arg=41944074) at eval.c:1226
#18 0x0009a550 in command_loop () at keyboard.c:1339
#19 0x0009a678 in recursive_edit_1 () at keyboard.c:954
#20 0x0009a804 in Frecursive_edit () at keyboard.c:1016
#21 0x00099e44 in main (argc=400, argv=0xbffff560) at emacs.c:1833

(gdb) up 1
#1  0x0015a2d8 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=0, do_display=0, wait_for_cell=41944074, wait_proc=0xa8f320, just_wait_proc=0) at process.c:4941
4941              nfds = ns_select
(gdb) info locals
timeout_reduced_for_timers = 0
channel = 22035053
nfds = 0
Available = {
   fds_bits = {64, 0 <repeats 31 times>}
}
Connecting = {
   fds_bits = {0 <repeats 32 times>}
}
check_connect = 0
check_delay = 0
no_avail = 0
xerrno = 0
proc = -1
timeout = {
   tv_sec = 100000, 
   tv_usec = 0
}
end_time = {
   tv_sec = 1462952, 
   tv_usec = 3680068
}
wait_channel = 6
got_some_input = 0
count = 17
(gdb) l
4936                }
4937    #endif
4938    #if defined (USE_GTK) || defined (HAVE_GCONF)
4939              nfds = xg_select
4940    #elif defined (HAVE_NS)
4941              nfds = ns_select
4942    #else
4943              nfds = select
4944    #endif
4945                            (max (max (max_process_desc, max_keyboard_desc),
(gdb)


Systems where this behavior occurs
----------------------------------

I've observed this behavior on two systems

  (a) Mac OS X 10.4.11

      GNU Emacs 23.1.91.2 (powerpc-apple-darwin8.11.0, NS apple-appkit-824.48) 
      of 2010-01-13

$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin".

$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


  (b) Mac OS X 10.6.2

      GNU Emacs 23.1.91.2 (x86_64-apple-darwin10.2.0, NS apple-appkit-1038.25) 
      of 2010-01-11

$ gdb --version
GNU gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

                                 * * *

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
/Applications/Emacs.app/Contents/Resources/etc/DEBUG.


In GNU Emacs 23.1.91.2 (powerpc-apple-darwin8.11.0, NS apple-appkit-824.48)
  of 2010-01-13 on spud.local
Windowing system distributor `Apple', version 10.3.824
configured using `configure  '--with-ns''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: C
   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.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
   shell-dirtrack-mode: t
   display-time-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
   blink-cursor-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t

Recent input:
<left> <return> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <up> <up> 
<up> <right> <right> <right> <right> <left> <right> 
M-x <up> <up> C-g C-g C-h f <return> C-x o <down> <right> 
<return> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> M-x e d b u 
<tab> <backspace> <backspace> e <tab> d e <tab> <return> 
C-x b <return> b _ <backspace> SPC a d d <tab> SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC C-g C-x 
o C-g C-g C-g <return> <return> C-g C-g <return> C-x 
b C-g C-g C-x C-b C-x k <return> M-x g d b <return> 
<return> b SPC a d d _ <tab> SPC C-x o C-g C-x o q 
<return> b <backspace> n <return> b SPC a d d _ <tab> 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC C-g 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> C-x o C-g C-g M-x 
r e p o r t - e m <tab> <return>

Recent messages:

Result: nil
  [2 times]
Result: t
  [3 times]
Result: #<buffer *gud-foo*>

Result: #<process gud-foo>

Quit [3 times]
Quit

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug debug mule-util edebug jka-compr
find-func help-mode view log-edit pcvs-util add-log gdb-ui byte-opt
bytecomp byte-compile advice help-fns advice-preload bindat json gud
ansi-color cc-mode cc-fonts cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs multi-isearch skeleton reftex-parse reftex-ref
vc vc-dispatcher supercite easy-mmode sendmail regi reftex-vcr
reftex-dcr reftex reftex-vars tex-mode shell latexenc vc-rcs conf-mode
newcomment grep compile comint ring dired bbdb-autoloads bbdb regexp-opt
timezone server paren time tooltip ediff-hook vc-hooks lisp-float-type
mwheel ns-win easymenu tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mldrag 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
loaddefs button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Nick Roberts]

 > I'd like to report a problem with M-x gdb in the Nextstep port of
 > emacs 23.1.91.  When gud mode is started with M-x gdb, tab completion
 > of symbols (i.e., gud-gdb-complete-command) causes emacs to hang.
 > 
 > The release announcement for emacs 23.1.91 noted a major change in M-x
 > gdb (<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg01109.html>)
 > and this seems to be new behavior in 23.1.91.

Do you mean it worked before this reversion?  That earlier GDB/MI code is the
future and I'd like to put it back on a branch in the Emacs repository but I
don't know if there are branches or how to list them using bzr.  I don't
really want my own branch as it probably wouldn't get checked out by anybody
else but a shared experimental branch would be good.

 >...
 >   6) At the (gdb) prompt, type "b add_", then TAB
 > 
 >   7) After pressing TAB, emacs becomes unresponsive.
 > 
 >      Emacs stays unresponsive until Ctrl-G is pressed.

On GNU/Linux this works fine for me with just one completion.

 > 
 > Observations from edebug
 > ------------------------
 > 
 > I've used M-x edebug-defun to instrument different functions in
 > gud.el, so that I could step through them with emacs debugger.  
 > 
 > Emacs seems to hang when evaluating the expression
 > 
 >    (get-buffer-process gud-comint-buffer)

More likely it hangs on accept-process-output.

Emacs uses the special purpose gdb command "complete".  I have noticed that it
can appear to hang when there are too many completions then typing C-c C-c
causes all these to spill into the GUD buffer.  On the command line you get
something like:

(top-gdb) b <TAB>
Display all 20671 possibilities? (y or n)

but that doesn't seem to be the case here.

-- 
Nick                                           http://users.snap.net.nz/~nickrob

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

>> The release announcement for emacs 23.1.91 noted a major change in M-x
>> gdb (<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg01109.html>)
>> and this seems to be new behavior in 23.1.91.

>Do you mean it worked before this reversion?  That earlier GDB/MI code is the
>future and I'd like to put it back on a branch in the Emacs repository but I
>don't know if there are branches or how to list them using bzr.  I don't
>really want my own branch as it probably wouldn't get checked out by anybody
>else but a shared experimental branch would be good.

Nick,

Thanks for writing back.

I tried the "steps to reproduce" with emacs 23.1.1.  23.1.1 has the
same behavior as 23.1.91 (i.e., hangs on step 7).  So in that sense,
the reversion did restore the earlier behavior.

The hanging behavior did not occur in the last major revision of emacs
(22.3.1).  But I realize that the emacs gdb interface has undergone a
lot of changes since then.


>> ...
>>   6) At the (gdb) prompt, type "b add_", then TAB
>>
>>   7) After pressing TAB, emacs becomes unresponsive.
>>
>>      Emacs stays unresponsive until Ctrl-G is pressed.

>On GNU/Linux this works fine for me with just one completion.

Agreed.  On my OpenSUSE 11.2 system (with gdb 6.8.91.20090930-2.4),
step 7 works fine, with just one completion.  I've observed the
hanging on three different versions of Mac OS X (10.4.11, 10.5.7,
10.6.2), but not on GNU/Linux.


>> Observations from edebug
>> ------------------------
>>
>> I've used M-x edebug-defun to instrument different functions in
>> gud.el, so that I could step through them with emacs debugger.
>>
>> Emacs seems to hang when evaluating the expression
>>
>>    (get-buffer-process gud-comint-buffer)

>More likely it hangs on accept-process-output.

>Emacs uses the special purpose gdb command "complete".  I have noticed that it
>can appear to hang when there are too many completions then typing C-c C-c
>causes all these to spill into the GUD buffer.  On the command line you get
>something like:
>
>(top-gdb) b <TAB>
>Display all 20671 possibilities? (y or n)
>
>but that doesn't seem to be the case here.

Agreed.  Using gdb directly from the command line on Mac OS X 10.4.11,
there are three completions.

---------------------------------
$ gdb foo
GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries .. done

(gdb) complete b add_
b add_fdes
b add_one
b add_profil
(gdb)
---------------------------------


Steve Revilak

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Nick Roberts]

 > (gdb) complete b add_
 > b add_fdes
 > b add_one
 > b add_profil
 > (gdb)

You could do M-x gdb-enable-debug, then 

(gdb) b b add_<TAB>

in the Gud buffer.

Then inspect gdb-debug-log (C-h v) to see if "complete b add_" gets sent to Gdb.

I suspect it does and this relates to Apple Gdb and the previous problem with ^M
characters.

You could also download and compile FSF Gdb on Mac (I can't remember if you
already have) and try that.


-- 
Nick                                           http://users.snap.net.nz/~nickrob

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]

>> (gdb) complete b add_
>> b add_fdes
>> b add_one
>> b add_profil
>> (gdb)

>You could do M-x gdb-enable-debug, then 
>
>(gdb) b b add_<TAB>
>
>in the Gud buffer.
>
>Then inspect gdb-debug-log (C-h v) to see if "complete b add_" gets sent to Gdb.

Neat trick. :)


>I suspect it does and this relates to Apple Gdb and the previous problem with ^M
>characters.

Here's what I tried.

   1. emacs -Q -nw foo.c
   2. M-x gdb RET foo RET
   3. M-x gdb-enable-debug
   4. "b add_<TAB>"  [hangs]
   5. C-g twice (stops hanging)
   6. C-h v gdb-debug-log RET

I'll attach the contents of the *Help* buffer as gdb-debug-log.txt.

The last cons in gdb-debug-log.txt is (send-item ... "complete b
add_\n").  The second and third cons's above (send-item) seem to
contain the completion output.


>You could also download and compile FSF Gdb on Mac (I can't remember if you
>already have) and try that.

I haven't had a chance to build an fsf gdb yet, but I'm downloading
gdb-7.0.1 now.  I'll try gdb 7.0.1 and let you know how it goes.

Steve

[-- Attachment #1.2: gdb-debug-log.txt --]
[-- Type: text/plain, Size: 1017 bytes --]

gdb-debug-log is a variable defined in `gdb-ui.el'.
Its value is shown below.

Documentation:
List of commands sent to and replies received from GDB.
Most recent commands are listed first.  This list stores only the last
`gdb-debug-log-max' values.  This variable is used to debug GDB-UI.

Value: 
((recv . "\r\n\x1a\x1apre-prompt\r\n(gdb) \r\n\x1a\x1aprompt\r\n")
 (recv . "No breakpoints or watchpoints.\r\n")
 (recv . "\r\n\x1a\x1apost-prompt\r\n")
 (send-item "server info breakpoints\n" gdb-info-breakpoints-handler)
 (recv . "\r\n\x1a\x1apre-prompt\r\n(gdb) \r\n\x1a\x1aprompt\r\n")
 (recv . "&\"\\n\\032\\032error-begin\\n\"\r\n~\"\\n\\032\\032error\\n\"\r\n^error,msg=\"No registers.\"\r\n(gdb) \r\n")
 (recv . "\r\n\x1a\x1apost-prompt\r\n")
 (send-item "server interpreter mi -stack-info-frame\n" gdb-frame-handler-1)
 (recv . "\r\n\x1a\x1apre-prompt\r\n(gdb) \r\n\x1a\x1aprompt\r\n")
 (recv . "b add_one\r\nb add_profil\r\n")
 (recv . "b add_fdes\r\n")
 (recv . "\r\n\x1a\x1apost-prompt\r\n")
 (send-item .
	    #("complete b add_\n" 9 15
	      (fontified t))))

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Nick Roberts]

 > Value: 
 > ((recv . "^M\n\x1a\x1apre-prompt^M\n(gdb) ^M\n\x1a\x1aprompt^M\n")
 >  (recv . "No breakpoints or watchpoints.^M\n")
 >  (recv . "^M\n\x1a\x1apost-prompt^M\n")
 >  (send-item "server info breakpoints\n" gdb-info-breakpoints-handler)
 >  (recv . "^M\n\x1a\x1apre-prompt^M\n(gdb) ^M\n\x1a\x1aprompt^M\n")
 >  (recv . "&\"\\n\\032\\032error-begin\\n\"^M\n~\"\\n\\032\\032error\\n\"^M\n^error,msg=\"No registers.\"^M\n(gdb) ^M\n")
 >  (recv . "^M\n\x1a\x1apost-prompt^M\n")
 >  (send-item "server interpreter mi -stack-info-frame\n" gdb-frame-handler-1)
 >  (recv . "^M\n\x1a\x1apre-prompt^M\n(gdb) ^M\n\x1a\x1aprompt^M\n")
 >  (recv . "b add_one^M\nb add_profil^M\n")
 >  (recv . "b add_fdes^M\n")
 >  (recv . "^M\n\x1a\x1apost-prompt^M\n")
 >  (send-item .
 > 	    #("complete b add_\n" 9 15
 > 	      (fontified t))))

I think the terminal settings in the GUD buffer must be different for recent
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                                           http://users.snap.net.nz/~nickrob

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

>I think the terminal settings in the GUD buffer must be different for recent
>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,

Thanks for the suggestion.  I'll experiment with these ideas (but it
may be a day or two before I have the chance to do so).

Cheers,

Steve

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 6560 bytes --]

>From: Nick Roberts <nickrob@snap.net.nz>

>I think the terminal settings in the GUD buffer must be different for recent
>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, 
    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



==================================================================

* Emacs 23.1.91

  - Emacs -Q -nw ~/foo.c

  - M-x gdb RET
    Run gdb (like this): gdb --annotate=3 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_<TAB>".  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_<TAB>".  Still hangs, and has to be cancelled with C-g.
  
  - type "shell stty -onlcr".  This does something interesting.  Figure
    1 shows the "foo.c" buffer before I type "shell stty -onlcr".

---- Figure 1 ---------------------------------------------------
#include <stdio.h>

static int add_one(int x) {
   return (x + 1);
}

int main(void) {
=>int y = 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 <stdio.h>

   static int add_one(int x) {
     return (x + 1);
   }

   int main(void) {
B =>int y = add_one(3);
     printf("%d\n", y);
     return 0;
   }
------------------------------------------------------------------

  - type "shell stty -a".  This time "onlcr" has changed to "-onlcr"

  - "b add_<TAB>" 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_<TAB>" 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.
    
  - "b add_<TAB>" 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_<TAB>" 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=3 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'".  

These symbols seem to cover the major steps in
gud-gdb-complete-command.


[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

>From: Nick Roberts <nickrob@snap.net.nz>

>You could also download and compile FSF Gdb on Mac (I can't remember if you
>already have) and try that.

Nick,

Unfortunately, I didn't have much luck with the FSF gdb.

On my PowerPC Mac (Mac OS X 10.4.11), gdb's top-level ./configure
script tells me

   *** This configuration is not supported in the following subdirectories:
       bfd opcodes gdb sim
       (Any other directories should still work fine.)

and doesn't generate a gdb/Makefile.

Running ./gdb/configure fails with

   configure: error: "*** Gdb does not support native target powerpc-apple-darwin8.11.0"

I see these results with gdb-7.0.1, gdb-7.0, and every gdb-6.x release
back through 6.2.


On my Intel Mac (Mac OS X 10.6.2), gdb-7.0.1's configure generates a
gdb/Makefile, but the compilation fails.  Likewise for gdb-7.0.
gdb-6.x tells me that

  configure: error: "*** Gdb does not support native target i386-apple-darwin10.2.0"

It looks like I'm stuck with Apple's gdb.

Steve

[-- Attachment #2: Type: application/pgp-signature, Size: 195 bytes --]

bug#5404: 23.1.91; Nextstep port: M-x gdb hangs in tab completion of symbols

[Nick Roberts]

 > Running ./gdb/configure fails with
 > 
 >    configure: error: "*** Gdb does not support native target powerpc-apple-darwin8.11.0"
 > 
 > I see these results with gdb-7.0.1, gdb-7.0, and every gdb-6.x release
 > back through 6.2.

Yes, Gdb 7.0+ only supports x86/x86_64 Darwin.

 > On my Intel Mac (Mac OS X 10.6.2), gdb-7.0.1's configure generates a
 > gdb/Makefile, but the compilation fails.  Likewise for gdb-7.0.
 > gdb-6.x tells me that
 > 
 >   configure: error: "*** Gdb does not support native target i386-apple-darwin10.2.0"
 > 
 > It looks like I'm stuck with Apple's gdb.

This one should work, I think, but you need to ask why you get an error on the
gdb mailing list (gdb@sourceware.org).

-- 
Nick                                           http://users.snap.net.nz/~nickrob

bug#5404: FIXED: Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

I've attempted to reproduce 5404 on Mac OS X 10.6.4  with

   GNU Emacs 23.2.91.1 (x86_64-apple-darwin10.4.0, NS apple-appkit-1038.32) of 2011-01-02

and

   (146:1)oatmeal.ma.runwaynine.com:~$ gdb --version
   GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May  5 04:36:56 UTC 2010)
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you are
   welcome to change it and/or distribute copies of it under certain conditions.
   Type "show copying" to see the conditions.
   There is absolutely no warranty for GDB.  Type "show warranty" for details.
   This GDB was configured as "x86_64-apple-darwin"

The behavior reported in 5404 does NOT occur in this configuration.


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

bug#5404: FIXED: Nextstep port: M-x gdb hangs in tab completion of symbols

[Steve Revilak]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]