bug#3794: Error in json from gdb-ui

bug#3794: Error in json from gdb-ui

[Herbert Euler]

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


Package: emacs
Version: 23.1.50.11

(This is the CVS HEAD version of emacs.)

I tried M-x gdb to run emacs under gdb.  The command line was

  gdb -i=mi ~/src/emacs/src/emacs

and I got the error '(json-object-format ":" 44).  Here is the backtrace:

Debugger entered--Lisp error: (json-object-format ":" 44)
  signal(json-object-format (":" 44))
  json-read-object()
  apply(json-read-object nil)
  json-read()
  json-read-object()
  apply(json-read-object nil)
  json-read()
  json-read-array()
  apply(json-read-array nil)
  json-read()
  json-read-object()
  apply(json-read-object nil)
  json-read()
  json-read-object()
  apply(json-read-object nil)
  json-read()
  json-partial-output("bkpt")
  gdb-breakpoints-list-handler-custom()
  gdb-breakpoints-list-handler()
  gdb-done-or-error("BreakpointTable={nr_rows=\"2\",nr_cols=\"6\",hdr=[{width=\"7\",alignment=\...
  gud-gdbmi-marker-filter("colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\"what\",...
  apply(gud-gdbmi-marker-filter "colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\"w...
  gud-marker-filter("colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\"what\",colhdr...
  gud-filter(#<process gud-emacs> "colhdr=\"Address\"},{width=\"40\",alignment=\"2\",col_name=\...

The content of buffer *partial-output-emacs* is attached, evaluating

  (let ((json-array-type 'list)) (json-read))

reproduces the error.  The above expression is the last one of `json-partial-output'
in gdb-mi.el

Regards,
Guanpeng Xu

_________________________________________________________________
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.

http://www.microsoft.com/windows/windowslive/products/photos.aspx

[-- Attachment #1.2: Type: text/html, Size: 2137 bytes --]

[-- Attachment #2: json-data --]
[-- Type: application/octet-stream, Size: 1131 bytes --]

{"BreakpointTable":{"nr_rows":"2","nr_cols":"6","hdr":[{"width":"7","alignment":"-1","col_name":"number","colhdr":"Num"},{"width":"14","alignment":"-1","col_name":"type","colhdr":"Type"},{"width":"4","alignment":"-1","col_name":"disp","colhdr":"Disp"},{"width":"3","alignment":"-1","col_name":"enabled","colhdr":"Enb"},{"width":"18","alignment":"-1","col_name":"addr","colhdr":"Address"},{"width":"40","alignment":"2","col_name":"what","colhdr":"What"}],"body":[{"number":"1","type":"breakpoint","disp":"keep","enabled":"y","addr":"0x00000000004a56bd","func":"abort","file":"emacs.c","fullname":"/home/xgp/src/emacs/src/emacs.c","line":"433","times":"0"},{"number":"2","type":"breakpoint","disp":"del","enabled":"y","addr":"0x00000000004c7cab","func":"init_sys_modes","file":"sysdep.c","fullname":"/home/xgp/src/emacs/src/sysdep.c","line":"1132","times":"0","script":{"silent","xgetptr Vinitial_window_system","set $tem = (struct Lisp_Symbol *) $ptr","xgetptr $tem->xname","set $tem = (struct Lisp_String *) $ptr","set $tem = (char *) $tem->data","if $tem[0] == 'x' && $tem[1] == '\0'","break x_error_quitter","end","continue"}}]}}

bug#3794: Error in json from gdb-ui

[Nick Roberts]

Herbert Euler writes:
 > 
 > Package: emacs
 > Version: 23.1.50.11

I think this should really go to emacs-pretest-bug@gnu.org as this is an unreleased
version of Emacs.  I think that works if you prefix the subject header with
"23.1.50; " or use M-x report-emacs-bug in the Emacs version which has the bug.

 > (This is the CVS HEAD version of emacs.)
 > 
 > I tried M-x gdb to run emacs under gdb.  The command line was
 > 
 >   gdb -i=mi ~/src/emacs/src/emacs
 > 
 > and I got the error '(json-object-format ":" 44).  Here is the backtrace:
 > 
 > Debugger entered--Lisp error: (json-object-format ":" 44)
 >   signal(json-object-format (":" 44))
 >   json-read-object()
 >   apply(json-read-object nil)
 >   json-read()
 > ...

This relates to Dmitry Dzhus's recent changes, so I'm cc'ing him.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

bug#3794: Error in json from gdb-ui

[Dmitry Dzhus]

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


> I tried M-x gdb to run emacs under gdb.  The command line was
>
>   gdb -i=mi ~/src/emacs/src/emacs
>
> and I got the error '(json-object-format ":" 44).  Here is the backtrace:

Thank you for reporting this bug.

I could reproduce your problem and I wrote a workaround which fixes the
bug for me. Could you please try the attached patch for gdb-mi.el?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gdb-mi-breakpoint-script-fix.patch --]
[-- Type: text/x-patch, Size: 2548 bytes --]

diff -r 36335b2a0438 -r 392a117f6afc gdb-mi.el
--- a/gdb-mi.el	Fri Jul 10 14:57:26 2009 +0400
+++ b/gdb-mi.el	Fri Jul 10 16:52:55 2009 +0400
@@ -1570,7 +1570,7 @@
   (with-current-buffer (gdb-get-buffer-create 'gdb-partial-output-buffer)
     (erase-buffer)))
 
-(defun json-partial-output (&optional fix-key)
+(defun json-partial-output (&optional fix-key fix-list)
   "Parse gdb-partial-output-buffer with `json-read'.
 
 If FIX-KEY is non-nil, strip all \"FIX-KEY=\" occurences from
@@ -1579,15 +1579,37 @@
 -break-info are examples of MI commands which issue such
 responses.
 
+If FIX-LIST is non-nil, \"FIX-LIST={..}\" is replaced with
+\"FIX-LIST=[..]\" prior to parsing. This is used to fix broken
+-break-info output when it contains breakpoint script field
+incompatible with GDB/MI output syntax.
+
 Note that GDB/MI output syntax is different from JSON both
 cosmetically and (in some cases) structurally, so correct results
 are not guaranteed."
   (with-current-buffer (gdb-get-buffer-create 'gdb-partial-output-buffer)
     (goto-char (point-min))
-    (while (re-search-forward (concat "[\\[,]\\(" fix-key "=\\)") nil t)
-      (replace-match "" nil nil nil 1))
-     (goto-char (point-min))
-     (insert "{")
+    (when fix-key
+      (save-excursion
+        (while (re-search-forward (concat "[\\[,]\\(" fix-key "=\\)") nil t)
+          (replace-match "" nil nil nil 1))))
+    (when fix-list
+      (save-excursion
+        ;; Find positions of brackets which enclose broken list
+        (while (re-search-forward (concat fix-list "={\"") nil t)
+          (let ((p1 (goto-char (- (point) 2)))
+                (p2 (progn (forward-sexp)
+                           (1- (point)))))
+            ;; Replace braces with brackets
+            (save-excursion
+              (goto-char p1)
+              (delete-char 1)
+              (insert "[")
+              (goto-char p2)
+              (delete-char 1)
+              (insert "]"))))))
+    (goto-char (point-min))
+    (insert "{")
     ;; Wrap field names in double quotes and replace equal sign with
     ;; semicolon.
     ;; TODO: This breaks badly with foo= inside constants
@@ -1691,7 +1713,7 @@
 
 (defun gdb-breakpoints-list-handler-custom ()
   (let ((breakpoints-list (gdb-get-field 
-                           (json-partial-output "bkpt")
+                           (json-partial-output "bkpt" "script")
                            'BreakpointTable 'body)))
     (setq gdb-breakpoints-list nil)
     (insert "Num\tType\t\tDisp\tEnb\tHits\tAddr       What\n")

[-- Attachment #3: Type: text/plain, Size: 1073 bytes --]


Background information:

That's one of the GDB/MI syntax inconsistencies coming up in this case.
The problem is caused by a script being attached to `init_sys_modes`
breakpoint in `.gdbinit`. When GDB/MI includes script information in
`-break-info`, it violates its own syntax by wrapping script field value
in curly braces (like for tuples) instead of brackets (like for lists,
which should be the case for script listing), for example:

script={"silent","xgetptr Vinitial_window_system","set $tem = ( struct
Lisp_Symbol *) $ptr","xgetptr $tem->xname","set $tem = (struct
Lisp_String *) $ptr","set $tem = (char *) $tem->data","if $tem[0] == 'x'
&& $tem[1] == '\0'","break x_error_quitter","end","continue"}

Whereas according to GDB/MI Output Syntax tuples (enclosed in {}) may
contain only variable=value pairs.

As the result, the JSON parser used in gdb-mi.el chokes. We handle this
nasty case by turning `script` value into what it's meant to be, which
is a list, by replacing { -> [ and ] -> }.
-- 
Happy Hacking.

http://sphinx.net.ru
む

bug#3794: Error in json from gdb-ui

[Glenn Morris]

Nick Roberts wrote:

> I think this should really go to emacs-pretest-bug@gnu.org as this
> is an unreleased version of Emacs.

For some time now, that address has been totally equivalent to bug-gnu-emacs.
cc'ing it after a bug has been filed just creates duplicate emails.

> I think that works if you prefix the subject header with "23.1.50; "
> or use M-x report-emacs-bug in the Emacs version which has the bug.

The subject prefix does nothing. M-x report-emacs-bug would send it to
emacs-pretest-bug, but as I said that makes no difference as to where
it ends up.

bug#3840: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Herbert Euler]

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


> From: dima@sphinx.net.ru
> To: herberteuler@hotmail.com
> CC: 3794@emacsbugs.donarmstrong.com; bug-gnu-emacs@gnu.org
> CC: nickrob@snap.net.nz
> Subject: Re: bug#3794: Error in json from gdb-ui
> Date: Fri, 10 Jul 2009 17:26:37 +0400
> 
> 
> > I tried M-x gdb to run emacs under gdb.  The command line was
> >
> >   gdb -i=mi ~/src/emacs/src/emacs
> >
> > and I got the error '(json-object-format ":" 44).  Here is the backtrace:
> 
> Thank you for reporting this bug.
> 
> I could reproduce your problem and I wrote a workaround which fixes the
> bug for me. Could you please try the attached patch for gdb-mi.el?

That patch works for me, too.  Thanks.

But here are some other problems:

1. When there's file .gdbinit in the directory of the debugged
program, and there're breakpoints in that file, M-x gdb showed those
breakpoints after started previously, while the new implementation
doesn't, unless requesting them explicitly with "info b".

2. The command "shell" is broken: In M-x gdb,

     shell ps aux | grep emacs

results in no output; but in a "real" gdb, the output looks like this:

     shell ps aux | grep emacs
     &"shell ps aux | grep emacs\n"
     xgp   4886  1.3  0.1 80796 25900 pts/1   T    09:38   0:08 emacs
     xgp   4936  0.3  0.1 77688 22568 pts/10  T+   09:39   0:02 ./emacs
     xgp   5209  0.0  0.1 28128 16548 pts/6   Ss+  09:46   0:00 /usr/local/bin/gdb -i=mi emacs
     xgp   5353  0.4  0.1 28184 16584 pts/1   S+   09:49   0:00 gdb -i=mi emacs
     xgp   5354  0.0  0.0 52800  976 pts/1    S+   09:49   0:00 bash -c ps aux | grep emacs
     xgp   5356  0.0  0.0 51124  688 pts/1    S+   09:49   0:00 grep emacs
     ^done

3. Previously, typing directly RET at the M-x gdb prompt repeats the
last command in history.  This is also what a "real" gdb does.  But
in the new implementation, this does nothing now.

As Nick said, this implementation is still in developing.  Should I
wait then?

Regards,
Guanpeng Xu

_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

[-- Attachment #2: Type: text/html, Size: 3134 bytes --]

bug#3845: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Dmitry Dzhus]

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

Herbert Euler wrote:

>> > I tried M-x gdb to run emacs under gdb.  The command line was
>> >
>> >   gdb -i=mi ~/src/emacs/src/emacs
>> >
>> > and I got the error '(json-object-format ":" 44).  Here is the backtrace:
>>
>> I could reproduce your problem and I wrote a workaround which fixes the
>> bug for me. Could you please try the attached patch for gdb-mi.el?
>
> That patch works for me, too.  Thanks.

It's in the trunk now.

> 2. The command "shell" is broken: In M-x gdb,
>
>      shell ps aux | grep emacs
>
> results in no output; but in a "real" gdb, the output looks like this:
>
>      shell ps aux | grep emacs
>      &"shell ps aux | grep emacs\n"
>      xgp   4886  1.3  0.1 80796 25900 pts/1   T    09:38   0:08 emacs
>      xgp   4936  0.3  0.1 77688 22568 pts/10  T+   09:39   0:02 ./emacs
>      xgp   5209  0.0  0.1 28128 16548 pts/6   Ss+  09:46   0:00 /usr/local/bin/gdb -i=mi emacs
>      xgp   5353  0.4  0.1 28184 16584 pts/1   S+   09:49   0:00 gdb -i=mi emacs
>      xgp   5354  0.0  0.0 52800  976 pts/1    S+   09:49   0:00 bash -c ps aux | grep emacs
>      xgp   5356  0.0  0.0 51124  688 pts/1    S+   09:49   0:00 grep emacs
>      ^done

Output of GDB's shell command goes as is straight to the terminal
without being prefixed by stream identifier (~, @, & etc.) Thus it's
harder to distinguish where this output should go (to GUD buffer, to MI
parser etc.) I managed to produce a small patch which does the trick for
simple shell commands like yours, but don't expect it to work with
`top(1)` for example. I've attached the patch. Let me know if you notice
that it breaks something.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Print shell command output in GUD buffer --]
[-- Type: text/x-patch, Size: 958 bytes --]

(gdbmi-record-list, gdb-shell): Redirect shell command output to GUD
buffer (Emacs bug #3794)

diff -r 3ba511c84066 gdb-mi.el
--- a/gdb-mi.el
+++ b/gdb-mi.el
@@ -1418,7 +1418,8 @@
     (gdb-stopped . "\\*stopped,?\\(.*?\n\\)")
     (gdb-running . "\\*running,\\(.*?\n\\)")
     (gdb-thread-created . "=thread-created,\\(.*?\n\\)")
-    (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)")))
+    (gdb-thread-exited . "=thread-exited,\\(.*?\n\\)")
+    (gdb-shell . "\\(\\(?:^.+\n\\)+\\)")))
 
 (defun gud-gdbmi-marker-filter (string)
   "Filter GDB/MI output."
@@ -1476,7 +1477,10 @@
     gdb-filter-output))
 
 (defun gdb-gdb (output-field))
-
+(defun gdb-shell (output-field)
+  (let ((gdb-output-sink gdb-output-sink))
+    (setq gdb-filter-output
+          (concat output-field gdb-filter-output))))
 ;; gdb-invalidate-threads is defined to accept 'update-threads signal
 (defun gdb-thread-created (output-field))
 (defun gdb-thread-exited (output-field)

[-- Attachment #3: Type: text/plain, Size: 258 bytes --]


> 3. Previously, typing directly RET at the M-x gdb prompt repeats the
> last command in history. This is also what a "real" gdb does. But in
> the new implementation, this does nothing now.

I've fixed the code which mimicks RET behaviour for GUD buffer.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Repeat last command on RET properly --]
[-- Type: text/x-patch, Size: 507 bytes --]

(gdb-send): Repeat last command on RET properly (Emacs bug #3794).

diff -r b45e93199252 gdb-mi.el
--- a/gdb-mi.el
+++ b/gdb-mi.el
@@ -1267,7 +1267,7 @@
     (let ((inhibit-read-only t))
       (remove-text-properties (point-min) (point-max) '(face))))
   ;; mimic <RET> key to repeat previous command in GDB
-  (if (not (string-match "^\\s+$" string))
+  (if (not (string= "" string))
       (setq gdb-last-command string)
     (if gdb-last-command (setq string gdb-last-command)))
   (if gdb-enable-debug

[-- Attachment #5: Type: text/plain, Size: 545 bytes --]


> As Nick said, this implementation is still in developing.  Should I
> wait then?

It's GSoC project, see http://emacswiki.org/emacs/GDB-MI/ for some
details. Don't wait, report bugs of Emacs trunk version as soon as you
encounter them, but _please_ file *different* reports for different
bugs.

I first put really bleeding changes to my Mercurial repo, then commit
them to Emacs upstream for further testing. Non-stop debugging support
will hit the trunk by the end of this week.
-- 
Happy Hacking.

http://sphinx.net.ru
む

bug#3794: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Herbert Euler]

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


I'm so sorry for the big delay.  I was not able to use computers these
days.

> > 2. The command "shell" is broken: In M-x gdb,
> >
> > shell ps aux | grep emacs
> >
> > results in no output; but in a "real" gdb, the output looks like this:
> >
> > shell ps aux | grep emacs
> > &"shell ps aux | grep emacs\n"
> > xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs
> > xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs
> > xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i=mi emacs
> > xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:00 gdb -i=mi emacs
> > xgp 5354 0.0 0.0 52800 976 pts/1 S+ 09:49 0:00 bash -c ps aux | grep emacs
> > xgp 5356 0.0 0.0 51124 688 pts/1 S+ 09:49 0:00 grep emacs
> > ^done
>
> Output of GDB's shell command goes as is straight to the terminal
> without being prefixed by stream identifier (~, @, & etc.) Thus it's
> harder to distinguish where this output should go (to GUD buffer, to MI
> parser etc.) I managed to produce a small patch which does the trick for
> simple shell commands like yours, but don't expect it to work with
> `top(1)` for example. I've attached the patch. Let me know if you notice
> that it breaks something.

I see.  The patch works very well.

I got an idea of how to catch the output of `top(1)': Setting up the
gud buffer to make it behave like a shell buffer temporarily during
the execution of the `shell' command, and switching back to make it
behave in the gdb way after seen `^done'.  However, this seems not to
be worthy implementing, because normally only simple shell commands
are executed via the `shell' command.

> > 3. Previously, typing directly RET at the M-x gdb prompt repeats the
> > last command in history. This is also what a "real" gdb does. But in
> > the new implementation, this does nothing now.
>
> I've fixed the code which mimicks RET behaviour for GUD buffer.

It works for me, thank you.

And here's another three problems:

4. Killing a gdb buffer won't send the `detach' command to the gdb
process, leaving the debugged process permentally being stopped.  This
is often unconvenient.

5. The commands like `while' and `if' cannot be handled correctly.
Combined with problem #4, this leads to a bad use case: After typing
such a command, the gdb process hangs, so the gdb buffer has to be
killed.  Then, the debugged process hangs and has to be killed.  As a
result, both the debugger and the debugged process have to be
restarted.

6. Completion should be done with the emacs completion feature,
i.e. try-completion, completing-read etc.

Regards,
Guanpeng Xu


_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/

[-- Attachment #2: Type: text/html, Size: 3348 bytes --]

bug#4035: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Dmitry Dzhus]

Herbert Euler wrote:

> I see.  The patch works very well.

Shell patch is in the trunk now.

>> > 3. Previously, typing directly RET at the M-x gdb prompt repeats the
>> > last command in history. This is also what a "real" gdb does. But in
>> > the new implementation, this does nothing now.
>>
>> I've fixed the code which mimicks RET behaviour for GUD buffer.
>
> It works for me, thank you.

RET behaviour patch is in the trunk now.

> 6. Completion should be done with the emacs completion feature,
> i.e. try-completion, completing-read etc.

Do you mean the completion of commands in GUD buffer?
-- 
Happy Hacking.

http://sphinx.net.ru
む

bug#3794: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Herbert Euler]

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


> > 6. Completion should be done with the emacs completion feature,
> > i.e. try-completion, completing-read etc.
>
> Do you mean the completion of commands in GUD buffer?

Yes.  Currently, completion behaves like this (the vertical bar `|'
indicates the cursor):

(gdb) b redis|                  ;; Hit TAB.
b redisplay_dont_pause
b redisplay_interface
b redisplay_internal
b redisplay_mode_lines
b redisplay_performed_directly_p
b redisplay_preserve_echo_area
b redisplay_window
b redisplay_window_0
b redisplay_window_1
b redisplay_window_error
b redisplay_windows
b redisplaying_p
(gdb) b redisplay |             ;; There is an extra space character
                                ;; after `redisplay'.  This seems to
                ;; be due to `redisplay' being an
                ;; available completion.

Previously, completion in gdb is done this way:

(gdb) b redis|                  ;; Hit TAB.
(gdb) b redisplay|              ;; The first time TAB is hit,
                                ;; completes to that match.
(gdb) b redisplay|              ;; Hit TAB again.
(gdb) b redisplay|              ;; And the *Completions* window is
                                ;; popped up to show all available
                ;; completions.

At that point, the user can type RET to accept `redisplay' as the
match, or type more characters and then try other completions.

Regards,
Guanpeng Xu

_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1

[-- Attachment #2: Type: text/html, Size: 3001 bytes --]

bug#3794: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Herbert Euler]

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


> > 6. Completion should be done with the emacs completion feature,
> > i.e. try-completion, completing-read etc.
> 
> Do you mean the completion of commands in GUD buffer?

Hmmm, I misunderstood your words.  Completions of command names
is another feature that should be done with the emacs completion feature,
but to me it is not as important as completions of other completable
arguments, such as function/variable names.

Regards,
Guanpeng Xu

_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1

[-- Attachment #2: Type: text/html, Size: 875 bytes --]

bug#3794: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Dmitry Dzhus]

Herbert Euler wrote:

> 4. Killing a gdb buffer won't send the `detach' command to the gdb
> process, leaving the debugged process permentally being stopped.  This
> is often unconvenient.

This should be fixed in CVS now: I've changed the code so that killing
GUD buffer sends `-target-detach` command to process.

> 5. The commands like `while' and `if' cannot be handled correctly.
> Combined with problem #4, this leads to a bad use case: After typing
> such a command, the gdb process hangs, so the gdb buffer has to be
> killed.  Then, the debugged process hangs and has to be killed.  As a
> result, both the debugger and the debugged process have to be
> restarted.

I think that probably it will be tricky to handle with the current GUD
pseudoCLI console we have. This will need further investigating.
-- 
Happy Hacking.

http://sphinx.net.ru
む

bug#3794: Several other problems in gdb-mi [RE: bug#3794: Error in json from gdb-ui]

[Nick Roberts]

 > 4. Killing a gdb buffer won't send the `detach' command to the gdb
 > process, leaving the debugged process permentally being stopped.  This
 > is often unconvenient.

I've reverted Dmitry's fix for this as detaching might not be what the user
wants and it can cause problems (bug#4375: can't kill killed gud buffer).

If you want to deatch the inferior you should do it manually with the GDB CLI
command "detach" before killing the GUD buffer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob