gdb with many windows: kill associated buffers doesn't always work

gdb with many windows: kill associated buffers doesn't always work

[Klaus Zeitler]

1. emacs -Q&
2. eval (setq gdb-many-windows t)
3. M-x gdb

Now when I finish my debug session, the associated buffers don't get killed
automatically.
When I restart gdb without killing those associated buffers, I see the same
behavior. But when I kill all associated buffers and then restart gdb, the
newly created associated buffers will be automatically killed when I finish
my gdb session.

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
"What do you give a man who has everything?" the pretty
teenager asked her mother. "Encouragement, dear," she replied.

gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

Klaus Zeitler writes:
 > 1. emacs -Q&
 > 2. eval (setq gdb-many-windows t)
 > 3. M-x gdb
 > 
 > Now when I finish my debug session, the associated buffers don't get killed
 > automatically.
 > When I restart gdb without killing those associated buffers, I see the same
 > behavior. But when I kill all associated buffers and then restart gdb, the
 > newly created associated buffers will be automatically killed when I finish
 > my gdb session.

I assume that by "when I finish my debug session" you mean something like
typing quit in the GUD buffer, so that the process is killed but not the GUD
buffer.  I'm not sure why you would want to type quit and not just kill
the GUD buffer to finish a debug session, but clearly its a legitimate
thing to do.  This problem can be avoided by reverting this change:

2006-03-26  Andreas Schwab  <schwab@suse.de>

	* progmodes/gud.el (gdb): Only complain about multiple debugging
	when the gdb process is still running.

which wouldn't allow more than one GUD session (live process or not) with
"-annotate=3".  

Andreas,

What are the benefits of this change?  I can see that you can keep the shell
history in a second GUD buffer but that seems of limited usefulness.  I can
see many problems if the user is allowed to start a new session without the
buffers of the first being killed first.

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

Re: gdb with many windows: kill associated buffers doesn't always work

[Klaus Zeitler]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
    Nick> 
    Nick> I assume that by "when I finish my debug session" you mean something
    Nick> like typing quit in the GUD buffer, so that the process is killed
    Nick> but not the GUD buffer.  I'm not sure why you would want to type
    Nick> quit and not just kill the GUD buffer to finish a debug session, but
    Nick> clearly its a legitimate thing to do.

It doesn't matter. Both, quit and kill gud buffer, have the same effect, i.e.
from the 2nd gdb session on (if I kill all the buffers from the first gdb
session) the associated buffers are killed (which is just fine IMHO).

    Nick> 	* progmodes/gud.el (gdb): Only complain about multiple debugging
    Nick> 	when the gdb process is still running.

This also seems like a good change to me. It was really annoying having emacs
complain about multiple sessions when the first one was already finished,
even though the gud buffer did still exist.

Klaus




-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
Tomorrow will be canceled due to lack of interest.

Re: gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

 >     Nick> I assume that by "when I finish my debug session" you mean
 >     something Nick> like typing quit in the GUD buffer, so that the process
 >     is killed Nick> but not the GUD buffer.  I'm not sure why you would
 >     want to type Nick> quit and not just kill the GUD buffer to finish a
 >     debug session, but Nick> clearly its a legitimate thing to do.
 > 
 > It doesn't matter. Both, quit and kill gud buffer, have the same effect, i.e.
 > from the 2nd gdb session on (if I kill all the buffers from the first gdb
 > session) the associated buffers are killed (which is just fine IMHO).

They shouldn't have the same effect: killing the GUD buffer should kill the
associated buffers, typin quit shouldn't.  I can see now that typing quit
and _then_ killing the GUD buffer can cause problems (even without Andreas's
change).  However, I still can't see a problem if quit isn't typed in the GUD
buffer.  Can you?  If so could you give me a precise recipe?

 >     Nick> 	* progmodes/gud.el (gdb): Only complain about multiple debugging
 >     Nick> 	when the gdb process is still running.
 > 
 > This also seems like a good change to me. It was really annoying having emacs
 > complain about multiple sessions when the first one was already finished,
 > even though the gud buffer did still exist.

As things stand it might be difficult to keep this behaviour.  What do
you do with the first buffer once it has already finished?


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

Re: gdb with many windows: kill associated buffers doesn't always work

[Klaus Zeitler]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
    Nick> 
    Nick> They shouldn't have the same effect: killing the GUD buffer should
    Nick> kill the associated buffers, typin quit shouldn't.

Why not, I like this behavior (even when it's not intentionally).
But I don't normally kill my gud buffer, when I start the next debug session,
I have all my previous commands in the history buffer and I can scroll up in
the gdb buffer look at previous results etc.
 
    Nick> However, I still can't see a problem if quit isn't typed in the GUD
    Nick> buffer.  Can you?

Seems you're right, I have to take this back. I guess I had forgotten
to kill all the associated buffers before I tried it again. Sorry.


    > * progmodes/gud.el (gdb): Only complain about multiple debugging
    > when the gdb process is still running.

    >> This also seems like a good change to me. It was really annoying having
    >> emacs complain about multiple sessions when the first one was already
    >> finished, even though the gud buffer did still exist.

    Nick> As things stand it might be difficult to keep this behaviour.  What do
    Nick> you do with the first buffer once it has already finished?

I hope we can find a way to keep Andreas change.


Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare. -- Blair Houghton

Re: gdb with many windows: kill associated buffers doesn't always work

[Andreas Schwab]

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

> What are the benefits of this change?

It is pointless to complain when the gdb process has died and you just
want to restart it.  Killing the buffer destroys all your valuable
history.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

 > > What are the benefits of this change?
 > 
 > It is pointless to complain when the gdb process has died and you just
 > want to restart it.  Killing the buffer destroys all your valuable
 > history.

The gdb process only dies if you quit the session.  If you want to restart it
then why would you type 'quit' in the first place when you can just type 'run'?

The point of complaining is that gdb-ui.el doesn't handle the case of two
GUD buffers properly.

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

Re: gdb with many windows: kill associated buffers doesn't always work

[Andreas Schwab]

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

> The gdb process only dies if you quit the session.

It can die for any reason.

> The point of complaining is that gdb-ui.el doesn't handle the case of two
> GUD buffers properly.

Which two buffers?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

 > > The gdb process only dies if you quit the session.
 > 
 > It can die for any reason.

If GDB crashes then thats a bug in GDB and this should rarely happen.  Could
you name a few other reasons?

 > > The point of complaining is that gdb-ui.el doesn't handle the case of two
 > > GUD buffers properly.
 > 
 > Which two buffers?

Which two buffers??  The first one i.e the GUD buffer with the killed process,
and the second one i.e the one that can be invoked because the current code
only complains about multiple debugging when the gdb process is still running.

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

Re: gdb with many windows: kill associated buffers doesn't always work

[Andreas Schwab]

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

>  > > The gdb process only dies if you quit the session.
>  > 
>  > It can die for any reason.
>
> If GDB crashes then thats a bug in GDB and this should rarely happen.

But it happens, and when it happens you don't want to lose all your
valuable history.

>  > > The point of complaining is that gdb-ui.el doesn't handle the case of two
>  > > GUD buffers properly.
>  > 
>  > Which two buffers?
>
> Which two buffers??  The first one i.e the GUD buffer with the killed process,
> and the second one i.e the one that can be invoked because the current code
> only complains about multiple debugging when the gdb process is still running.

I still don't see where the second buffer appears when it is reused.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

 > > If GDB crashes then thats a bug in GDB and this should rarely happen.
 > 
 > But it happens, and when it happens you don't want to lose all your
 > valuable history.

Well, if its that valuable you could presumably save it with 'set logging on'.

 >...
 > > Which two buffers??  The first one i.e the GUD buffer with the killed
 > > process, and the second one i.e the one that can be invoked because the
 > > current code only complains about multiple debugging when the gdb process
 > > is still running.
 > 
 > I still don't see where the second buffer appears when it is reused.

Sorry, I'm thinking of the case where GDB is invoked with a different
executable on the second occasion (although there are problems even when
the executable is the same, as Klaus pointed out).


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

Re: gdb with many windows: kill associated buffers doesn't always work

[Andreas Schwab]

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

> Sorry, I'm thinking of the case where GDB is invoked with a different
> executable on the second occasion (although there are problems even when
> the executable is the same, as Klaus pointed out).

How about switching the buffer to fundamental-mode before continuing?
That will wipe out all local variables, but lets you keep the contents.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gdb with many windows: kill associated buffers doesn't always work

[Stefan Monnier]

>> > The gdb process only dies if you quit the session.
>> It can die for any reason.
> If GDB crashes then thats a bug in GDB and this should rarely happen.

"Should" is the operative word here.

> Could you name a few other reasons?

Even if it doesn't crash, it can get into a state that I find easier to
cleanup by quit&restart than by trying to figure out whether the situation
can be salvaged and how.  It may even happen without any bug whatsoever,
just because you've set enough GDB envvars and options and you want to reset
them to some default state.  Maybe GDB offers such a command, but using
quit&restart has the advantage that it's a universal way to do it,
non-specific to GDB.


        Stefan

Re: gdb with many windows: kill associated buffers doesn't always work

[Nick Roberts]

 > >> > The gdb process only dies if you quit the session.
 > >> It can die for any reason.
 > > If GDB crashes then thats a bug in GDB and this should rarely happen.
 > 
 > "Should" is the operative word here.

Well it rarely happens to me.  Please report such occurances to the GDB
mailing list to help stop this happening.

 > > Could you name a few other reasons?
 > 
 > Even if it doesn't crash, it can get into a state that I find easier to
 > cleanup by quit&restart than by trying to figure out whether the situation
 > can be salvaged and how.  It may even happen without any bug whatsoever,
 > just because you've set enough GDB envvars and options and you want to reset
 > them to some default state.  Maybe GDB offers such a command, but using
 > quit&restart has the advantage that it's a universal way to do it,
 > non-specific to GDB.

OK, I hear that people are saying that they may want to keep the GUD buffer.
I now see that I made a mistake in gud-sentinel in gud.el.

Klaus,

Does the patch below give you the behaviour you want?


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



*** gud.el	24 May 2006 09:21:32 +1200	1.107
--- gud.el	24 May 2006 09:24:48 +1200	
*************** It is saved for when this flag is not se
*** 2693,2702 ****
  	((memq (process-status proc) '(signal exit))
  	 ;; Stop displaying an arrow in a source file.
  	 (setq gud-overlay-arrow-position nil)
! 	 (with-current-buffer gud-comint-buffer
! 	   (if (memq gud-minor-mode-type '(gdbmi gdba))
! 	       (gdb-reset)
! 	     (gud-reset)))
  	 (let* ((obuf (current-buffer)))
  	   ;; save-excursion isn't the right thing if
  	   ;;  process-buffer is current-buffer
--- 2693,2702 ----
  	((memq (process-status proc) '(signal exit))
  	 ;; Stop displaying an arrow in a source file.
  	 (setq gud-overlay-arrow-position nil)
! 	 (if (memq (buffer-local-value 'gud-minor-mode gud-comint-buffer)
! 		   '(gdba gdbmi))
! 	     (gdb-reset)
! 	   (gud-reset))
  	 (let* ((obuf (current-buffer)))
  	   ;; save-excursion isn't the right thing if
  	   ;;  process-buffer is current-buffer

Re: gdb with many windows: kill associated buffers doesn't always work

[Klaus Zeitler]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
    Nick> 
    Nick> Does the patch below give you the behaviour you want?

Yes, works nicely now. Deletes all the associated buffers and allows for
different gud buffers (as long as only one is running). Great.
Thanks

Klaus

-- 
 ------------------------------------------
|  Klaus Zeitler      Lucent Technologies  |
|  Email:             kzeitler@lucent.com  |
 ------------------------------------------
---
The porcupine with the sharpest quills gets stuck on a tree more often.