gdbui hang

gdbui hang

[Miles Bader]

Sometimes (well, actually fairly often) the new fancy gdb mode hangs in
a way that can't be interrupted, e.g.:

   ...
   Program exited normally.
   (gdb) break poc_startup
   Function "poc_startup" not defined.
   Make breakpoint pending on future shared library load? (y or [n]) n

     C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c

I'm not sure what other info is useful to debug this.

[A related problem is that if I kill the *gud-foo* buffer to try and
recover from the hang, and then start another gdb process, it will often
fail to work, saying `selecting deleted buffer' in a command I give.  In
general it's a good idea to recover gracefully if a buffer is deleted;
the gdb mode probably shouldn't be keeping any session state outside of
the gdb buffer itself -- i.e., try to make any state variables
buffer-local in the gdb session buffer.]

-Miles
-- 
Run away!  Run away!

Re: gdbui hang

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Sometimes (well, actually fairly often) the new fancy gdb mode hangs in
> a way that can't be interrupted, e.g.:
> 
>    ...
>    Program exited normally.
>    (gdb) break poc_startup
>    Function "poc_startup" not defined.
>    Make breakpoint pending on future shared library load? (y or [n]) n
> 
>      C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c
> 
> I'm not sure what other info is useful to debug this.

I have seen similar problems if I set a breakpoints at some location
(using C-x SPC) while the program is running; then I go to the gud
buffer and type C-c C-z to stop the process.

This seems to work, but sometimes it's like gud and gdb are no longer
in sync.  If I try to delete the breakpoint (e.g. d 4) it gets worse.
If I then continue the program, c, I can no longer interrupt it with
C-c C-z.

Maybe you need to set two breakpoints at the same location (do C-x SPC
twice) to see this.

Sorry that I cannot be more precise.

> 
> [A related problem is that if I kill the *gud-foo* buffer to try and
> recover from the hang, and then start another gdb process, it will often
> fail to work, saying `selecting deleted buffer' in a command I give.  In
> general it's a good idea to recover gracefully if a buffer is deleted;
> the gdb mode probably shouldn't be keeping any session state outside of
> the gdb buffer itself -- i.e., try to make any state variables
> buffer-local in the gdb session buffer.]

I've seen this too -- to me it looks like there is a process filter still
running somewhere which tries to use a deleted buffer...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

gdbui hang

[Nick Roberts]

 > Sometimes (well, actually fairly often) the new fancy gdb mode hangs in
 > a way that can't be interrupted, e.g.:
 > 
 >    ...
 >    Program exited normally.
 >    (gdb) break poc_startup
 >    Function "poc_startup" not defined.
 >    Make breakpoint pending on future shared library load? (y or [n]) n
 > 
 >      C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c  C-c C-c

Pending breakpoints are a new feature of GDB 6.1. I can see that the
output annotation (nquery) for this is different to earlier ones (query).
I'll install a fix in gdb-ui.el and and ask GDB developers whether this
annotation is a feature or a bug.

Nick

Re: gdbui hang

[Stefan Monnier]

> Pending breakpoints are a new feature of GDB 6.1. I can see that the
> output annotation (nquery) for this is different to earlier ones (query).
> I'll install a fix in gdb-ui.el and and ask GDB developers whether this
> annotation is a feature or a bug.

Is there some way to make gdbui somewhat resilient to such changes?


        Stefan

Re: gdbui hang

[Nick Roberts]

 > Is there some way to make gdbui somewhat resilient to such changes?

If GDB developers add new and undocumented annotations then it makes matters
difficult. I will ask them not to do this and perheps this new annotation
could be backed out in an imminent respin of GDB (6.1.1).

I'm sure GDB developers would say "switch to GDB/MI", but I'm not finding this
as easy as it sounds.

Nick

Re: gdbui hang

[Richard Stallman]

    If GDB developers add new and undocumented annotations then it makes matters
    difficult. I will ask them not to do this and perheps this new annotation
    could be backed out in an imminent respin of GDB (6.1.1).

    I'm sure GDB developers would say "switch to GDB/MI", but I'm not finding this
    as easy as it sounds.

Please write to them, and cc the message to me, so I can second
the request.

Re: gdbui hang

[Miles Bader]

On Mon, May 10, 2004 at 07:42:37PM +0100, Nick Roberts wrote:
> If GDB developers add new and undocumented annotations then it makes matters
> difficult. I will ask them not to do this and perheps this new annotation
> could be backed out in an imminent respin of GDB (6.1.1).

Is it not possible to at least deal more gracefully with such situations?

The new gdbui mode seems to get wedged in these unrecoverable states way too
often, and seems way too fragile... (with traditional gdb mode, hitting C-g a
few times and then C-c C-c a few times was usually enough to get you back
into some known state).

-Miles
-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: gdbui hang

[Nick Roberts]

 > Is it not possible to at least deal more gracefully with such situations?

I think this case was unusual. gdb-ui will normally recognise that annotations
that GDB outputs.

 > The new gdbui mode seems to get wedged in these unrecoverable states way too
 > often, and seems way too fragile... (with traditional gdb mode, hitting C-g a
 > few times and then C-c C-c a few times was usually enough to get you back
 > into some known state).

For each GDB command the user types, it runs several behind the users back to
keep Emacs informed about the status of the program being debugged. This
requires careful co-ordination and will take just take time to iron out the
bugs. I can only suggest that you submit a bug report for each case.

Nick

Re: gdbui hang

[Miles Bader]

On Tue, May 11, 2004 at 09:25:51PM +0100, Nick Roberts wrote:
>  > The new gdbui mode seems to get wedged in these unrecoverable states way
>  > too often, and seems way too fragile... (with traditional gdb mode,
>  > hitting C-g a few times and then C-c C-c a few times was usually enough
>  > to get you back into some known state).
> 
> For each GDB command the user types, it runs several behind the users back to
> keep Emacs informed about the status of the program being debugged. This
> requires careful co-ordination and will take just take time to iron out the
> bugs. I can only suggest that you submit a bug report for each case.

Yes, I fully understand your dilemna, but the bugs in gdbui typically seem
pretty hard to describe in a useful way -- often it just hangs, and won't
unhang -- and are not easily repeatable.

Is there some internal state that be useful to quote in a bug report?  Even
better, how about a dump-gdbui-internal-state command that could be used
when sending a bug report?

Thanks,

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: gdbui hang

[Nick Roberts]

 > Yes, I fully understand your dilemna, but the bugs in gdbui typically seem
 > pretty hard to describe in a useful way -- often it just hangs, and won't
 > unhang -- and are not easily repeatable.
 > 
 > Is there some internal state that be useful to quote in a bug report?  Even
 > better, how about a dump-gdbui-internal-state command that could be used
 > when sending a bug report?

If they are repeatable, you could set the variable gdb-enable-debug-log
(which records the transactions between gdb and emacs) to t, trigger the bug
and post the value of gdb-debug-log to emacs-devel.

If they're not repeatable, maybe you could start with gdb-enable-debug-log
set to t  and post the last part of gdb-debug-log to emacs-devel. I've
not tried this though, and gdb-debug-log might get very large and slow things
down.

Nick

Re: gdbui hang

[Stefan Monnier]

>> For each GDB command the user types, it runs several behind the users
>> back to keep Emacs informed about the status of the program being
>> debugged. This requires careful co-ordination and will take just take
>> time to iron out the bugs. I can only suggest that you submit a bug
>> report for each case.

A good starting point would be some kind of M-x gdb-resync RET.

> Is there some internal state that be useful to quote in a bug report?  Even
> better, how about a dump-gdbui-internal-state command that could be used
> when sending a bug report?

There's a log of the send/receive communication in gdb-debug-log
which is accumulated if you turn on gdb-enable-debug-log.


        Stefan

gdbui hang

[Nick Roberts]

 > [A related problem is that if I kill the *gud-foo* buffer to try and
 > recover from the hang, and then start another gdb process, it will often
 > fail to work, saying `selecting deleted buffer' in a command I give.  In
 > general it's a good idea to recover gracefully if a buffer is deleted;
 > the gdb mode probably shouldn't be keeping any session state outside of
 > the gdb buffer itself -- i.e., try to make any state variables
 > buffer-local in the gdb session buffer.]

This is because kill-buffer sends SIGHUP to the associated process. If GDB is
expecting input (as in the case you describe) then the process is immune to
SIGHUP and doesn't get killed.  Try this, even with the old GUD, type
list-buffers and you get something like:


Proc         Status   Buffer         Tty         Command
----         ------   ------         ---         -------
gud-myprog   run      (Killed)	     /dev/pts/4	 gdb -fullname /home/nick/myprog

Since the process is not killed, gud-sentinel doesn't get called and, in the
case of gdb-ui, the associated buffers stay there. To run gdb again requires
that these buffers (partial-output, breakpoints etc) are deleted first. 
"kill -9" will kill the GDB process but leave the inferior process.

Its messy, I agree, but I don't have an answer to this one. 

Does anybody else have a solution?

Nick

Re: gdbui hang

[Stefan Monnier]

> This is because kill-buffer sends SIGHUP to the associated process.
[...]
> Its messy, I agree, but I don't have an answer to this one. 

Add a kill-buffer-hook in the GUD buffer to kill the process (and the
related buffers).  Also add a check at the place where you select a buffer
that might be dead and if it's indeed dead clean things up as best you can.


        Stefan

Re: gdbui hang

[Nick Roberts]

 > Add a kill-buffer-hook in the GUD buffer to kill the process (and the
 > related buffers).  Also add a check at the place where you select a buffer
 > that might be dead and if it's indeed dead clean things up as best you can.

Changing gud-kill-buffer-hook like this seems to work (gud-sentinel cleans
things up):

(defun gud-kill-buffer-hook ()
  (when (eq (current-buffer) gud-comint-buffer)
      (setq gud-minor-mode-type gud-minor-mode)
      (kill-process (get-buffer-process gud-comint-buffer))))

kill-process sends SIGKILL but I don't know why this kills the inferior (child
process of gdb) because SIGKILL doesn't do this if I run gdb from an xterm.

Shall I commit this change?

Nick

Re: gdbui hang

[Stefan Monnier]

> (defun gud-kill-buffer-hook ()
>   (when (eq (current-buffer) gud-comint-buffer)
>       (setq gud-minor-mode-type gud-minor-mode)
>       (kill-process (get-buffer-process gud-comint-buffer))))

In general I think the add-hook should not be global but only apply to the
*gud* buffer.  But I must say that I don't understand at all what the
current gud-kill-buffer-hook is doing:

   % grep -nH gud-minor-mode-type  *.el
   gud.el:2504:(defvar gud-minor-mode-type nil)
   gud.el:2512:	 (if (eq gud-minor-mode-type 'gdba)
   gud.el:2549:      (setq gud-minor-mode-type gud-minor-mode)))

It's a variable used in the process sentinel but only set when
a gud-minor-mode buffer is killed.  Sounds pretty odd, yet there's no
comment explaniing what going on.  Sounds like a bug (or some left over
code).

> kill-process sends SIGKILL but I don't know why this kills the inferior (child
> process of gdb) because SIGKILL doesn't do this if I run gdb from an xterm.

I don't know either, but I suspect it has to do with the fact that
terminating the process will also eliminate the tty, so it's more like
killing the whole xterm.

> Shall I commit this change?

Given that it changes the current behavior in ways I don't understand
(because I don't understand the current behavior), I can't tell.
But you might want to check that `get-buffer-process' returns non-nil.


        Stefan

Re: gdbui hang

[Nick Roberts]

 > In general I think the add-hook should not be global but only apply to the
 > *gud* buffer.

kill-buffer-hook *is* a global variable, though. gud-kill-buffer-hook does
only apply to the *gud* buffer though the condition (eq (current-buffer)
gud-comint-buffer). What's there to make local?

 >          But I must say that I don't understand at all what the
 > current gud-kill-buffer-hook is doing:
 > 
 >    % grep -nH gud-minor-mode-type  *.el
 >    gud.el:2504:(defvar gud-minor-mode-type nil)
 >    gud.el:2512:	 (if (eq gud-minor-mode-type 'gdba)
 >    gud.el:2549:      (setq gud-minor-mode-type gud-minor-mode)))
 > 
 > It's a variable used in the process sentinel but only set when
 > a gud-minor-mode buffer is killed.  Sounds pretty odd, yet there's no
 > comment explaniing what going on.  Sounds like a bug (or some left over
 > code).

I wrote that code, a while back. Here's my logic:

gud-sentinel needs to do different things depending on whether gdb is run
with "-fullname" (gud-minor-mode = 'gdb) or "-annotate=3" or
(gud-minor-mode = 'gdba). gud-sentinel is executed after the buffer is killed
and so can't deduce which case it is dealing with. However,
gud-kill-buffer-hook is run before the buffer is killed, so it is used to
store gud-minor-mode in the variable gud-minor-mode-type.

 > > Shall I commit this change?
 > 
 > Given that it changes the current behavior in ways I don't understand
 > (because I don't understand the current behavior), I can't tell.
 > But you might want to check that `get-buffer-process' returns non-nil.

How about:

(defun gud-kill-buffer-hook ()
  (when (eq (current-buffer) gud-comint-buffer)
    (setq gud-minor-mode-type gud-minor-mode)
    (condition-case nil
	(kill-process (get-buffer-process gud-comint-buffer))
      (error nil))))

Nick

Re: gdbui hang

[Stefan Monnier]

>> In general I think the add-hook should not be global but only apply to the
>> *gud* buffer.
> kill-buffer-hook *is* a global variable, though. gud-kill-buffer-hook does
> only apply to the *gud* buffer though the condition (eq (current-buffer)
> gud-comint-buffer).  What's there to make local?

Se the `local' arg of ad-hook.

>> But I must say that I don't understand at all what the
>> current gud-kill-buffer-hook is doing:
>> 
>> % grep -nH gud-minor-mode-type  *.el
>> gud.el:2504:(defvar gud-minor-mode-type nil)
>> gud.el:2512:	 (if (eq gud-minor-mode-type 'gdba)
>> gud.el:2549:      (setq gud-minor-mode-type gud-minor-mode)))
>> 
>> It's a variable used in the process sentinel but only set when
>> a gud-minor-mode buffer is killed.  Sounds pretty odd, yet there's no
>> comment explaniing what going on.  Sounds like a bug (or some left over
>> code).

> I wrote that code, a while back. Here's my logic:

> gud-sentinel needs to do different things depending on whether gdb is run
> with "-fullname" (gud-minor-mode = 'gdb) or "-annotate=3" or
> (gud-minor-mode = 'gdba).  gud-sentinel is executed after the buffer is
> killed and so can't deduce which case it is dealing with.  However,
> gud-kill-buffer-hook is run before the buffer is killed, so it is used to
> store gud-minor-mode in the variable gud-minor-mode-type.

Ah I see.  [ Reminds me that I'd like to add property lists to processes. ]
But in this particular case, I guess the best approach is to merge
gdb-reset into gud-reset so the sentinel doesn't have to care about the
difference between various gud-minor-mode.

BTW: the regexp "^\*.+*$" in gdb-reset should probably be "\\`\\*.+\\*\\'"
[ or even thrown away and replaced with something like a buffer-local variable
`gud-auxiliary-buffer' which would be set to non-nil (better yet: to the
main *gud* buffer) in those *foo* buffers. ]

> (defun gud-kill-buffer-hook ()
>   (when (eq (current-buffer) gud-comint-buffer)
>     (setq gud-minor-mode-type gud-minor-mode)
>     (condition-case nil
> 	(kill-process (get-buffer-process gud-comint-buffer))
>       (error nil))))

Sure.  Except I'd add the hook buffer-locally so you don't need to check
(eq (current-buffer) gud-comint-buffer).


        Stefan

Re: gdbui hang

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 
> Ah I see.  [ Reminds me that I'd like to add property lists to processes. ]

Huh?

Functions process-put and process-get (which use process-plist
and set-process-plist) are already in CVS emacs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdbui hang

[Stefan Monnier]

>> Ah I see.  [ Reminds me that I'd like to add property lists to processes. ]
> Huh?
> Functions process-put and process-get (which use process-plist
> and set-process-plist) are already in CVS emacs.

Hmmm... looks like I should follow my own advice and read C-h
N more assiduously.  Thanks,


        Stefan