GNU bug report logs - #13845
24.3.50; gud commands stop responding when using gdb-mi

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13845 in the body.
You can then email your comments to 13845 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; gud commands stop responding when using gdb-mi
Date: Thu, 28 Feb 2013 21:02:56 -0500

When debugging a program using gdb-mi, the gud commands (gud-break for
instance) stop responding.  I get the problem all the time on the
trunk version of Emacs (revision 111899).  I have gdb version 7.5.1
installed.  The following steps should reproduce the problem:

Start Emacs:
  cd trunk/src
  ./emacs -Q

Start a another Emacs in gdb-mi.  Use the CLI interface to start the program:
  M-x gdb
  Run gdb (like this): gdb -i=mi emacs
  (gdb) run

Back in the first emacs, break GDB:
  C-c C-c

Open one of the Emacs source file (emacs.c)
  C-x C-f
  Find file: ../trunk/src/emacs.c

In the function main, position the cursor on a line of code and try to
set a break point using the gud command:
  M-x gud-break

The break point is successfully created.  Return to the *gud-emacs*
buffer and resume the debugged Emacs, then break again:
  (gdb) continue
  C-c C-c

Go back in the emacs.c file and try to set a breakpoint again in the
main function.  From this point on, the gud-break will refuse to work.
 The internal state of gdb-mi is in fact in a stall.  Several other
features of gdb-mi are also disabled.  For instance, if you start
gdb-many-windows:
  M-x gdb-many-windows

and click on the Threads tab, the buffer will be empty even though the
debugged program isn't running.

I investigated the problem and found it's root in the gdb-mi.el file.
When typing "run" in the debugger, GDB responds with a "^running"
message.  gdb-mi handles this by calling the gdb-starting function.
In this function, you will find the following:
  (defun gdb-starting (_output-field)
    [...]
    ;; GDB doesn't seem to respond to -thread-info before first stop or
    ;; thread exit (even in non-stop mode), so this is useless.
    ;; Behavior may change in the future.
    (gdb-emit-signal gdb-buf-publisher 'update-threads))

Indeed, GDB doesn't respond to the -thread-info command.
Nevertheless, gdb-mi records the -thread-info request in the variable
gdb-pending-trigger and will refuse to send any other -thread-info
command until GDB responds the command gdb-mi is waiting for.

Back to our stalled gdb-mi, if we probe the gdb-pending-trigger
variable, we get:
  C-h v
  Describe variable: gdb-pending-trigger
    gdb-pending-triggers is a variable defined in `gdb-mi.el'.
    Its value is ((#<buffer *threads of emacs*> . gdb-invalidate-threads))

We can get back on our feet by clearing that variable:
  M-:
  Eval: (setq gdb-pending-triggers nil)

and then run a CLI command in GDB:
  (gdb) where

Only resetting the variable is not enough on it's own, but running a
CLI command right after seems to wake-up gdb-mi out of it's coma.
After this, you can run gud commands again and gdb-many-windows is
back to life.

Commenting out the (gdb-emit-signal gdb-buf-publisher 'update-threads)
statement in both gdb-starting and gdb-running helps quite a bit, but
this fix is not enough.  I sometimes encounter cases where gdb-mi
fails to receive replies for a bunch of other commands to update all
other gdb window (breakpoints, call-stack, etc.)  Unfortunately, this
condition is harder to encounter and I cannot provide repro-steps at
this point.

I do not know if this should be considered an emacs or a GDB bug
(should GDB always reply to commands, even when the program is
running?)  What I can say for sure is that there is definitively room
for improvement on the emacs side: the pending message handling should
be more robust and gdb-mi should not hang if GDB skips a reply.


In GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-02-28 on ubuntu
Bzr revision: 111899 juri <at> jurta.org-20130228215111-mwv0v6velfkb8vbw
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.1 LTS

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  gdb-many-windows: t
  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
  abbrev-mode: t

Recent input:
M-x g d b <return> <C-backspace> <C-backspace> e m
a c s <return> r u n <return> C-c C-c C-x C-f e m a
c s . c <return> C-s m a i n SPC ( C-s <down> <down>
<down> C-x SPC C-x b <return> c o n t i n u e <return>
C-c C-c C-x b <return> <down> <down> C-x SPC C-x b
<return> M-x g d b - m a n y - w i n d o w <return>
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo>
<help-echo> <help-echo> C-h v g d b - p e n d i n g
<tab> <return> q M-: ( s e t q SPC g d b - p e n d
i n <tab> t r <tab> SPC n i l ) <return> w h e r e
<return> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <down-mouse-1> <mouse-1> C-x SPC <help-echo>
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Switched to thread 1
Loading cc-langs...done
Mark saved where search started
Command: break emacs.c:654
Gdb-Many-Windows mode enabled
Type "q" to restore previous buffer.
nil
Command: break emacs.c:656

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils pp help-mode help-fns cus-start cus-load
misearch multi-isearch vc-bzr cc-langs cl nadvice cl-lib cc-mode
cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs gdb-mi bindat json gud easy-mmode comint ansi-color ring
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
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 macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

Message #8 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: 13845 <at> debbugs.gnu.org
Subject: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Mon, 29 Apr 2013 23:32:51 -0400

Hi,

I have a fix ready for this bug.  I just got write access to the
repository and this will be the first commit I do on my own. I would
therefore like to request a code review to make sure I got everything
right.

My branch is available on launchpad:
https://code.launchpad.net/~jpgravel/emacs/bug13845

Please consider all revisions from 112234 to 112242.  Revision 112233
is already in the trunk.

The core of this branch consists of a rework of the way pending
triggers are implemented.  The new implementation will allow easy
cleanup of dead pending triggers, whenever they are detected.  There
used to be two lists to keep track of the commands sent to gdb:
gdb-handler-alist and gdb-pending-triggers.  The first one was storing
the callback to invoke when receiving the reply form GDB, the second
was flagging some of those commands as pending, to prevent GDB from
sending the same commands until the reply is received.  With my
changes, the two lists are merged into gdb-handler-list, making it
easier to cleanly insert and remove handlers.

I thought of two ways of detecting dead pending triggers:
 1 - It seems that GDB always replies in the same order Emacs sends
commands.  Replies from GDB are therefore always received in
increasing numerical order.  Based on this observation, we can remove
old pending triggers as soon as newer replies are received from GDB.
 2 - We could add a timeout mechanism that would remove pending
triggers if no replies is received after a certain amount of time.

With this branch, I only implemented option 1, which can be
enabled/disabled using `gdb-discard-unordered-replies'.  I may
implement Option 2 in a subsequent commit.

Regarding this branch, I have three questions:
 - I needed the function cl-find-if and cl-delete-if.  It seems there
is a long history about not using the functions from cl.el at runtime.
 It also seems that lots of devs simply re-implemented those functions
in their own modules.  I couldn't find the functions I needed in a
genetic utility package (other than cl.el).  Instead, I found them
re-implemented as erc-delete-if and org-find-if.  For now, I copied
those two functions in gdb-mi.el but I can't help but wonder if there
is a place where those functions could be moved so that different
modules could share their implementation.
 - I removed two strange ^L characters in gdb-mi.el.  Am I right to
remove them?  Do they mean anything, or are they garbage ASCII
character that got there by mistake?
 - When doing my commit, do I need to specify a bug tracker with the
--fixes option, or is "--fixes 13845" enough?

Thanks,
Jean-Philippe

Message #11 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jean-Philippe Gravel <jpgravel <at> gmail.com>
Cc: 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Tue, 30 Apr 2013 14:54:13 -0400

Jean-Philippe Gravel wrote:

> My branch is available on launchpad:
> https://code.launchpad.net/~jpgravel/emacs/bug13845
>
> Please consider all revisions from 112234 to 112242.  Revision 112233
> is already in the trunk.

Could you send the change you propose to install to this address as a
flat diff? I'm assuming it is not enormous.

>  - I needed the function cl-find-if and cl-delete-if.  It seems there
> is a long history about not using the functions from cl.el at runtime.

It is fine to use cl-lib at runtime, so no problem.

>  - I removed two strange ^L characters in gdb-mi.el.  Am I right to
> remove them? 

No. (And as a general comment don't mix unrelated formatting changes
with commits.)

> Do they mean anything, or are they garbage ASCII
> character that got there by mistake?

They are page separators. See (emacs)Pages.

>  - When doing my commit, do I need to specify a bug tracker with the
> --fixes option, or is "--fixes 13845" enough?

Add an entry to ~/.bazaar/bazaar.conf:

  [DEFAULT]
  bugtracker_debbugs_url = http://debbugs.gnu.org/{id}

then use --fixes debbugs:13845

Message #14 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Tue, 30 Apr 2013 22:46:29 -0400

[Message part 1 (text/plain, inline)]

Glenn Morris wrote:

> Could you send the change you propose to install to this address as a
> flat diff? I'm assuming it is not enormous.

Certainly.  I divided my branch into three distinct patches that could
be committed separately.

[invalidSignals.patch (text/x-patch, attachment)]

[bug13845.patch (text/x-patch, attachment)]

[tokenNumber.patch (text/x-patch, attachment)]

Message #17 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jean-Philippe Gravel <jpgravel <at> gmail.com>
Cc: 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Wed, 01 May 2013 22:20:35 -0400

Thanks. I'm not familiar with gdb, so these are style comments only.

Jean-Philippe Gravel wrote:

> + 	* progmodes/gdb-mi.el (gdb-running, gdb-starting): Removed
> + 	signals for which replies were never received.

Use the present tense for ChangeLog entries.

> + 	(gdb-wait-for-pending): Fix invalid backquote. Use gdb-handler-list.
> + 	instead of gdb-pending-triggers. Update docstring.

Two spaces between sentences.

> ! (defcustom gdb-discard-unordered-replies t
> !   "When non-nil, any out-of-order GDB replies are discarded.

Use the active voice; eg

  Non-nil means discard any out-of-order GDB replies.

> ! This mechanism is provided as a protection against lost GDB replies,
> ! assuming that GDB always replies in the same order Emacs is sending
> ! commands.  When receiving a reply with a given token-number, any
> ! pending messages with a lower token-number are considered out-of-order.

  This protects against lost GDB replies, assuming that GDB always
  replies in the same order as Emacs sends commands.  When receiving a
  reply with a given token-number, assume any pending messages with a
  lower token-number are out-of-order.

> ! (cl-defstruct gdb-handler
> !   "Structure used to keep track of the commands sent to GDB and
> ! handle the replies received."

First line of doc should be a complete sentence.

> ! Handlers are used to keep track the commands sent to GDB and to handle the

Remove "keep", or add "of" (keep track of).

> ! replies received.  TOKEN-NUMBER is the number used as prefix of the GDB/mi
> ! command sent. 

Active voice: Use TOKEN-NUMBER as the prefix...

> ! Upon reception of a reply prefixed with the same TOKEN-NUMBER,
> ! the callback HANDLER-FUNCTION is invoked.

active: invoke the callback...

> ! Additionally, if `gdb-discard-unordered-replies' is non-nil, all handlers
> ! having a token number less than TOKEN-NUMBER are discarded."

active: discard all handlers...

> ! This involves invoking the callback registered with this token number
> ! in `gdb-handler-list' and clearing all pending handlers invalidated
> ! by the reception of this reply."

This invokes the handler ... and clears all pending...

Message #20 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Jean-Philippe Gravel <jpgravel <at> gmail.com>, 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Sun, 05 May 2013 01:28:16 -0400

> Thanks. I'm not familiar with gdb, so these are style comments only.

Other than Glenn's comments, it looks fine, thank you.
Just one more detail:

The text in the ChangeLog files should ideally be redundant (i.e. we
should be able to regenerate it from the commit log), so please make
sure you use the same text for the commit messages (tho with the leading
TABs removed) as the text you wrote in the ChangeLog.

If you commit from vc-dir you should be able to use C-c C-a from the
*VC-Log* buffer to grab the commit message from the ChangeLog files
(tho it seems it currently only works if you tell VC exactly which files
you want to commit, rather than just telling it to commit the top
directory).


        Stefan

Message #23 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Sun, 5 May 2013 22:05:46 -0400

Hi Glenn and Stefan,

Thank's for the review.  I will make the correction you propose and go
ahead with the commit.

Jean-Philippe

On Sun, May 5, 2013 at 1:28 AM, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> Thanks. I'm not familiar with gdb, so these are style comments only.
>
> Other than Glenn's comments, it looks fine, thank you.
> Just one more detail:
>
> The text in the ChangeLog files should ideally be redundant (i.e. we
> should be able to regenerate it from the commit log), so please make
> sure you use the same text for the commit messages (tho with the leading
> TABs removed) as the text you wrote in the ChangeLog.
>
> If you commit from vc-dir you should be able to use C-c C-a from the
> *VC-Log* buffer to grab the commit message from the ChangeLog files
> (tho it seems it currently only works if you tell VC exactly which files
> you want to commit, rather than just telling it to commit the top
> directory).
>
>
>         Stefan

Message #26 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Tue, 14 May 2013 14:52:07 -0400

> Thank's for the review.  I will make the correction you propose and go
> ahead with the commit.

Done.

Message #29 received at 13845 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jean-Philippe Gravel <jpgravel <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 13845 <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Tue, 14 May 2013 15:23:13 -0400

Jean-Philippe Gravel wrote:

>> Thank's for the review.  I will make the correction you propose and go
>> ahead with the commit.
>
> Done.

Thanks. As final step, please close this report, by sending a mail to
13845-done <at> debbugs.

Message #34 received at 13845-done <at> debbugs.gnu.org (full text, mbox):

From: Jean-Philippe Gravel <jpgravel <at> gmail.com>
To: 13845-done <at> debbugs.gnu.org
Subject: Re: bug#13845: 24.3.50; gud commands stop responding when using gdb-mi
Date: Tue, 14 May 2013 21:47:13 -0400

Closing report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.