bug#4375: 23.1.50; can't kill killed gud buffer

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

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.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Maybe associated with the other gdb error I have just reported.
If I run gud with --annotate=3
I get lots of pre-prompt and post-prompt output
(perhaps this is to be expected), I kill the process with a signals KILL
- off the pulldown menu) and if I then attempt to kill the *gud ...*
buffer I get the message

gdb-input: Buffer *gud-ipsa-scripted* has no process

and the buffer is not killed :-(

Robert

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'.
If you would like to further debug the crash, please read the file
/home/robert/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.1.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.1)
 of 2009-09-08 on robert-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.10600000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  desktop-save-mode: t
  recentf-mode: t
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

-- 
Robert A J Marshall,  
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
tel: +44 161 615 6017; fax: +44 161 615 6001; mobile: +44 7759 688384 
web: http://IPSA-Power.com 

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > Maybe associated with the other gdb error I have just reported.
 > If I run gud with --annotate=3
 > I get lots of pre-prompt and post-prompt output
 > (perhaps this is to be expected), I kill the process with a signals KILL
 > - off the pulldown menu) and if I then attempt to kill the *gud ...*
 > buffer I get the message
 > 
 > gdb-input: Buffer *gud-ipsa-scripted* has no process
 > 
 > and the buffer is not killed :-(

That does seem to be a bug, I have a look at it.  However, Emacs 23.1.50
should run GDB using GDB/MI (gdb -i=mi) not annotations (gdb --annotate=3)
so you shouldn't see any pre-prompt and post-prompt output.  I don't know
if you've customized gud-gdb-command-name or if your're manually editing
in the mini-buffer but you need to start with something like:

Run gdb (like this): gdb -i=mi yourprog

and you shouldn't need to kill the debugger.  Note that to stop the inferior
(program being debugged) you use C-c C-c (comint-interrupt-subjob) which
is signals BREAK on the pulldown menu.


 > ...
 > In GNU Emacs 23.1.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.1)
 >  of 2009-09-08 on robert-laptop

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

Nick Roberts wrote:
>  > Maybe associated with the other gdb error I have just reported.
>  > If I run gud with --annotate=3
>  > I get lots of pre-prompt and post-prompt output
>  > (perhaps this is to be expected), I kill the process with a signals KILL
>  > - off the pulldown menu) and if I then attempt to kill the *gud ...*
>  > buffer I get the message
>  >
>  > gdb-input: Buffer *gud-ipsa-scripted* has no process
>  >
>  > and the buffer is not killed :-(
>
>  That does seem to be a bug, I have a look at it.  However, Emacs 23.1.50
>  should run GDB using GDB/MI (gdb -i=mi) not annotations (gdb --annotate=3)
>  so you shouldn't see any pre-prompt and post-prompt output.  I don't know
>  if you've customized gud-gdb-command-name or if your're manually editing
>  in the mini-buffer but you need to start with something like:
>
>  Run gdb (like this): gdb -i=mi yourprog
>
>  and you shouldn't need to kill the debugger.  Note that to stop the 
inferior
>  (program being debugged) you use C-c C-c (comint-interrupt-subjob) which
>  is signals BREAK on the pulldown menu.
>
>
>  > ...
>  > In GNU Emacs 23.1.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.1)
>  >  of 2009-09-08 on robert-laptop
>
Looks as if my earlier bug report hasn't appeared (the other bug was why 
I was trying --annotate)
If I run with -i=mi I get lots of

    mi_cmd_stack_info_frame: No arguments required
messages. Also if I try turning on tooltips when I hold the mouse over a 
variable I get the message

    error in process filter: Args out of range: "", 0, -1
There's also a longish wait on startup when it is turning off non stop mode
and I see the message there
    No symbol "non" in current context.
in the gdb buffer, I don't know if that is expected?

If I then do a quit in the debugger I also get the message about the 
process not running.

Robert

-- 
Robert A J Marshall, 
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
tel: +44 161 615 6017; fax: +44 161 615 6001; mobile: +44 7759 688384
web: http://IPSA-Power.com

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > Looks as if my earlier bug report hasn't appeared (the other bug was why 
 > I was trying --annotate)
 > If I run with -i=mi I get lots of
 > 
 >     mi_cmd_stack_info_frame: No arguments required
 > messages.

Even if "-i=mi" doesn't work for you "--annotate" is not the answer.  The mode
in 23.1.50 really needs GDB 7.0, which han't been released yet!  There used to
be two GDB releases per year but the last was back in March of last year.  It's
hard to co-ordinate changes but the aim is for it to be released shortly.

 >          Also if I try turning on tooltips when I hold the mouse over a 
 > variable I get the message
 >
 >     error in process filter: Args out of range: "", 0, -1

Yes I can see that this with GDB 7.0 - so that's another bug.  Thanks for the
report.

 > There's also a longish wait on startup when it is turning off non stop mode
 > and I see the message there
 >
 >     No symbol "non" in current context.
 > in the gdb buffer, I don't know if that is expected?

This is related to old GDB.  Emacs enquires if it can run these versions of
GDB in non-stop mode but can't prevent the display of the resultant error
message because it is duplicated in the console output, which goes to the GUD
buffer.

 > If I then do a quit in the debugger I also get the message about the 
 > process not running.

Hmm, I don't know but if you can get GDB 7.0 most (but not all) of these problems
will clear up.  If you need to use GDB in earnest it's probably best to use the
released Emacs 23.1 which uses "--annotate".  However, if you have some time,
then I appreciate bug reports for Emacs 23.1.50.  Ultimately this latter mode
will be much better than the current one but it depends on users making bug
reports because I don't use it that often now.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Jan D.]

9 sep 2009 kl. 11.12 skrev nickrob@snap.net.nz (Nick Roberts):

>> Looks as if my earlier bug report hasn't appeared (the other bug  
>> was why
>> I was trying --annotate)
>> If I run with -i=mi I get lots of
>>
>>    mi_cmd_stack_info_frame: No arguments required
>> messages.
>
> Even if "-i=mi" doesn't work for you "--annotate" is not the  
> answer.  The mode
> in 23.1.50 really needs GDB 7.0, which han't been released yet!

Are you saying that when 23.2 is released Gdb 7.0 will be required?

Can the 23.1 gdb-mode work with 23.1.50? I'd really like to be able to  
debug with gdb-mode in the current CVS trunk. Installing Gdb 7.0 is  
not an option.

      Jan D.

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > > in 23.1.50 really needs GDB 7.0, which han't been released yet!
 > 
 > Are you saying that when 23.2 is released Gdb 7.0 will be required?

I had anticipated that 23.2 would be released from the EMACS_23_1_RC branch
i.e. the branch on which Emacs 21.1 was released, as with Emacs 21.2 and Emacs
22.2.  I must admit I've not followed discussion on emacs-devel closely.

 > Can the 23.1 gdb-mode work with 23.1.50? I'd really like to be able to  
 > debug with gdb-mode in the current CVS trunk. Installing Gdb 7.0 is  
 > not an option.

If the release of 23.2 is imminent then I could temporarily move gdb-ui.el
back from EMACS_23_1_RC for the release.  It also has some new features,
e.g. reverse debugging.

Is installing Gdb 7.0 not an option once it has been released?

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Stefan Monnier]

> If the release of 23.2 is imminent then I could temporarily move
> gdb-ui.el back from EMACS_23_1_RC for the release.  It also has some
> new features, e.g. reverse debugging.

Even if it's not imminent, it's likely that when it will happen many
people will still be using older GDB releases.  So it'd be good to keep
the gdb-ui.el code for Emacs-23.2 (and include the new gdb-mi.el as
well).

BTW, as you probably already know, I really think that M-x gdb should Do
the Right Thing, whether gdb is run with --annotate=2, --annotate=3,
or -i=mi.  I.e. it should wait to see GDB's output and then decide based
on that output whether to use gdb-mi.el or gdb-ui.el or just gud.el.

> Is installing Gdb 7.0 not an option once it has been released?

I don't understand this question.


        Stefan

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > > If the release of 23.2 is imminent then I could temporarily move
 > > gdb-ui.el back from EMACS_23_1_RC for the release.  It also has some
 > > new features, e.g. reverse debugging.
 > 
 > Even if it's not imminent, it's likely that when it will happen many
 > people will still be using older GDB releases.  So it'd be good to keep
 > the gdb-ui.el code for Emacs-23.2 (and include the new gdb-mi.el as
 > well).

Emacs 23.1 is always an option for those using older GDB releases.  Migrating
properly to GDB/MI is not an easy thing to do and I want to focus on that
rather than on compatibility with old versions of GDB.  Others can work on
maintaining compatibility if they wish but it will make the code a lot more
complicated.


 > BTW, as you probably already know, I really think that M-x gdb should Do
 > the Right Thing, whether gdb is run with --annotate=2, --annotate=3,
 > or -i=mi.  I.e. it should wait to see GDB's output and then decide based
 > on that output whether to use gdb-mi.el or gdb-ui.el or just gud.el.

We used to do that with "--fullname" and "--annotate=3" but that caused
problems when execution was started in the users .gdbinit file.  The two
options are now invoked with separate functions (M-x gud-gdb and M-x gdb).


 > > Is installing Gdb 7.0 not an option once it has been released?
 > 
 > I don't understand this question.

I wondered what was preventing Jan from using GDB 7.0.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Stefan Monnier]

> Emacs 23.1 is always an option for those using older GDB releases.

Rather you mean "using gud-gdb is always an option for those using older
GDB releases" (we're talking about what to do for Emacs-23.2, so we
take for granted that the user will be using Emacs-23.2).
That might be good enough (I personally always end up using gud-gdb
since I've always found M-x gdb to be somewhat unreliable).

> properly to GDB/MI is not an easy thing to do and I want to focus on that
> rather than on compatibility with old versions of GDB.

Preserving the gdb-ui.el code should be doable without any interference
with gdb-mi.el.  The code they share via gud.el is pretty small.

>> BTW, as you probably already know, I really think that M-x gdb should Do
>> the Right Thing, whether gdb is run with --annotate=2, --annotate=3,
>> or -i=mi.  I.e. it should wait to see GDB's output and then decide based
>> on that output whether to use gdb-mi.el or gdb-ui.el or just gud.el.
> We used to do that with "--fullname" and "--annotate=3" but that caused
> problems when execution was started in the users .gdbinit file.  The two
> options are now invoked with separate functions (M-x gud-gdb and M-x gdb).

I know, but I still think this is a temporary workaround.  We should
document it well in some comments to make sure someone who wants to
attack the problem doesn't waste time going through the same problems
agains.


        Stefan

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > > Emacs 23.1 is always an option for those using older GDB releases.
 > 
 > Rather you mean "using gud-gdb is always an option for those using older
 > GDB releases" (we're talking about what to do for Emacs-23.2, so we
 > take for granted that the user will be using Emacs-23.2).
 > That might be good enough (I personally always end up using gud-gdb
 > since I've always found M-x gdb to be somewhat unreliable).

No I don't, I mean M-x gdb in Emacs 23.1 is always an option for those using
older GDB releases (although it may depend how old, gdb-ui.el is better with
6.4 and later but should work back to 5.0 from 2000).

M-x gud-gdb should work in Emacs 23.1.50 as it does in Emacs 23.1.

I don't know what you mean by unreliable, but over the years, in my
experience, M-x gdb has become more reliable.  Of course if you have a highly
customized environment, the results might be different and buffers might
appear in strange places.  If you are having problems, I would recommend
starting with gdb-many-windows nil and then the startup should be similar
gud-gdb except that you can set breakpoints/control execution in the margin
and see the breakpoint locations there.  Then you could display new buffers in
new frames, as and when needed, by using the pull down menu: GUD >
GDB-Frames-> <desired GDB buffer>.

 > > We used to do that with "--fullname" and "--annotate=3" but that caused
 > > problems when execution was started in the users .gdbinit file.  The two
 > > options are now invoked with separate functions (M-x gud-gdb and M-x gdb).
 > 
 > I know, but I still think this is a temporary workaround.  We should
 > document it well in some comments to make sure someone who wants to
 > attack the problem doesn't waste time going through the same problems
 > agains.

On the contrary, I would like to remove gud-gdb at some point in the future.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Jan D.]

10 sep 2009 kl. 06.13 skrev nickrob@snap.net.nz (Nick Roberts):

> M-x gud-gdb should work in Emacs 23.1.50 as it does in Emacs 23.1.
>

That is good!  But I think 5

bug#4375: 23.1.50; can't kill killed gud buffer

[Jan D.]

10 sep 2009 kl. 11.04 skrev "Jan D." <jan.h.d@swipnet.se>:

>
>
> 10 sep 2009 kl. 06.13 skrev nickrob@snap.net.nz (Nick Roberts):
>
>> M-x gud-gdb should work in Emacs 23.1.50 as it does in Emacs 23.1.
>>
>
> That is good!  But I think

... that M-x gdb should be gud-gdb and the new mode should have  
another name. At least until Gdb 7.0 isn't so new and uncommon.

Most people don't read NEWS.

     Jan D.

bug#4375: 23.1.50; can't kill killed gud buffer

[Jan D.]

9 sep 2009 kl. 23.55 skrev nickrob@snap.net.nz (Nick Roberts):

>>> Is installing Gdb 7.0 not an option once it has been released?
>>
>> I don't understand this question.
>
> I wondered what was preventing Jan from using GDB 7.0.
>

Different things. Policy for one, i.e. the tools to use are version  
controlled locally. Much work for another. Many older distros will  
never upgrade Gdb. To compile it on many machines is a big job (I  
don't mind doing it for Emacs since I test and develop Emacs).

IMHO this 7.0 requirement will make gdb-mode useless for the majority  
of users. Do we even know if 7.0 is released before 23.2 is? The  
strength of gdb-mode in the past is that you just did M-x gdb and it  
worked with whatever Gdb version you had.

     Jan D.

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > > I wondered what was preventing Jan from using GDB 7.0.
 > >
 > 
 > Different things. Policy for one, i.e. the tools to use are version  
 > controlled locally. Much work for another. Many older distros will  
 > never upgrade Gdb. To compile it on many machines is a big job (I  
 > don't mind doing it for Emacs since I test and develop Emacs).

Maybe your use pattern, i.e. Emacs in CVS and old GDB, is somewhat unusual.  I
would expect most users to have released versions of both programs, probably
those which are included in their distribution.

 > IMHO this 7.0 requirement will make gdb-mode useless for the majority  
 > of users. Do we even know if 7.0 is released before 23.2 is? The  
 > strength of gdb-mode in the past is that you just did M-x gdb and it  
 > worked with whatever Gdb version you had.

I expect GDB 7.0 to be released before Emacs 23.2 in which case it's likely
that when 23.2 is bundled with a distribution that will include 7.0 too.  I'm
more concerned about the quality of the mode being worthy for inclusion in the
release.

In any case, at the moment we're talking about bleeding edge Emacs in CVS.
I'm not sure it's reasonable to expect such a version to be stable enough to
debug itself and it would seem more natural to use a release version for such
a purpose.

I don't think that requiring 7.0 will make gdb-mode useless but, in truth, I
don't know who uses it, or how they use it.  I guess that would need a poll
and even then those that repond are likely to be unrepresentative.


and:

 > ... that M-x gdb should be gud-gdb and the new mode should have  
 > another name. At least until Gdb 7.0 isn't so new and uncommon.

I think that to swap back now that Emacs 23.1 has been released will only
cause confusion.

 > Most people don't read NEWS.

No, but hopefully they will read the documentation.  If not, then all is
pretty much lost anyway.


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

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > Also if I try turning on tooltips when I hold the mouse over a 
 > variable I get the message
 > 
 >     error in process filter: Args out of range: "", 0, -1

This bit should now work with GDB 7.0.  I've no managed to get this
error with earlier GDB but then I've not managed to get the tooltip
to appear in this case either.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

Nick Roberts wrote:
>  > Also if I try turning on tooltips when I hold the mouse over a 
>  > variable I get the message
>  > 
>  >     error in process filter: Args out of range: "", 0, -1
>
> This bit should now work with GDB 7.0.  I've no managed to get this
> error with earlier GDB but then I've not managed to get the tooltip
> to appear in this case either.
>
>   
I see the same things - no error and no tooltip.

Robert

-- 
Robert A J Marshall,  
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
web: http://IPSA-Power.com 

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 >             ... and if I then attempt to kill the *gud ...*
 > buffer I get the message
 > 
 > gdb-input: Buffer *gud-ipsa-scripted* has no process
 > 
 > and the buffer is not killed :-(

I think I've fixed this now.  If it works for you can you please close the bug
report by replying to 4375-done@emacsbugs.donarmstrong.com.

If there are other outstanding problems please open a new bug report.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

Nick Roberts wrote:
>  >             ... and if I then attempt to kill the *gud ...*
>  > buffer I get the message
>  > 
>  > gdb-input: Buffer *gud-ipsa-scripted* has no process
>  > 
>  > and the buffer is not killed :-(
>
> I think I've fixed this now.  If it works for you can you please close the bug
> report by replying to 4375-done@emacsbugs.donarmstrong.com.
>
> If there are other outstanding problems please open a new bug report.
>
>   
Though with these changes after I've quit the debugger and attempt to close
emacs, I get the following message

Active processes exist; kill them and exit anyway...

Proc         Status   Buffer   Tty      Command
----         ------   ------   ---      -------
gdb-inferior run      (Killed) /dev/pts/3

Do you want a new bug for this?

Robert

-- 
Robert A J Marshall,  
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
web: http://IPSA-Power.com 

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > Though with these changes after I've quit the debugger and attempt to close
 > emacs, I get the following message
 > 
 > Active processes exist; kill them and exit anyway...
 > 
 > Proc         Status   Buffer   Tty      Command
 > ----         ------   ------   ---      -------
 > gdb-inferior run      (Killed) /dev/pts/3
 > 
 > Do you want a new bug for this?

I only see this now if I kill the I/O buffer directly.  Do you still see it if
you kill the GUD buffer (as recommended in the manual to kill all the buffers
associated with the session)?

If so, did you recompile both gdb-mi.el and gud.el before you loaded them?

I need to handle killing the I/O buffer directly and I'll look into it when I
have time.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

Nick Roberts wrote:
>  > Though with these changes after I've quit the debugger and attempt to close
>  > emacs, I get the following message
>  > 
>  > Active processes exist; kill them and exit anyway...
>  > 
>  > Proc         Status   Buffer   Tty      Command
>  > ----         ------   ------   ---      -------
>  > gdb-inferior run      (Killed) /dev/pts/3
>  > 
>  > Do you want a new bug for this?
>
> I only see this now if I kill the I/O buffer directly.  Do you still see it if
> you kill the GUD buffer (as recommended in the manual to kill all the buffers
> associated with the session)?
>
>   

No I don't see it in this case - previously I'd left the *gud... buffer 
still open

> If so, did you recompile both gdb-mi.el and gud.el before you loaded them?
>
> I need to handle killing the I/O buffer directly and I'll look into it when I
> have time.
>
>   
OK.

What I'm also seeing is is an error when I've placed a break point
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  propertize(nil font-lock-face font-lock-function-name-face)
  gdb-breakpoints-list-handler-custom()
  gdb-breakpoints-list-handler()
  apply(gdb-breakpoints-list-handler nil)
...
if you don't easily see this I will open another bug.

Robert

-- 
Robert A J Marshall,  
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
web: http://IPSA-Power.com 

bug#4375: 23.1.50; can't kill killed gud buffer

[Nick Roberts]

 > What I'm also seeing is is an error when I've placed a break point
 > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 >   propertize(nil font-lock-face font-lock-function-name-face)
 >   gdb-breakpoints-list-handler-custom()
 >   gdb-breakpoints-list-handler()
 >   apply(gdb-breakpoints-list-handler nil)
 > ...
 > if you don't easily see this I will open another bug.

I don't see this.  Please do open a new bug report with precise steps to
reproduce it.

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

bug#4375: 23.1.50; can't kill killed gud buffer

[Robert Marshall]

Nick Roberts wrote:
>  > What I'm also seeing is is an error when I've placed a break point
>  > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>  >   propertize(nil font-lock-face font-lock-function-name-face)
>  >   gdb-breakpoints-list-handler-custom()
>  >   gdb-breakpoints-list-handler()
>  >   apply(gdb-breakpoints-list-handler nil)
>  > ...
>  > if you don't easily see this I will open another bug.
>
> I don't see this.  Please do open a new bug report with precise steps to
> reproduce it.
>
>   
Will do, at the moment I can replicate it very easily with the (c++)
program (and emacs -Q) I'm developing but not with a small test program
or with running emacs under gdb. I may be a little time...!

Robert

-- 
Robert A J Marshall,

bug#4375: marked as done (23.1.50; can't kill killed gud buffer)

[Emacs bug Tracking System]

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

Your message dated Thu, 10 Sep 2009 09:34:54 +0100
with message-id <4AA8BA2E.3020005@tnei.co.uk>
and subject line Re: bug#4375: 23.1.50; can't kill killed gud buffer
has caused the Emacs bug report #4375,
regarding 23.1.50; can't kill killed gud buffer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4375: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4375
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 4444 bytes --]

From: Robert Marshall <robert.marshall@tnei.co.uk>
To: emacs-pretest-bug@gnu.org
Subject: 23.1.50; can't kill killed gud buffer
Date: Tue, 08 Sep 2009 16:08:38 +0100
Message-ID: <87ljkp79u1.fsf@tnei.co.uk>


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.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Maybe associated with the other gdb error I have just reported.
If I run gud with --annotate=3
I get lots of pre-prompt and post-prompt output
(perhaps this is to be expected), I kill the process with a signals KILL
- off the pulldown menu) and if I then attempt to kill the *gud ...*
buffer I get the message

gdb-input: Buffer *gud-ipsa-scripted* has no process

and the buffer is not killed :-(

Robert

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'.
If you would like to further debug the crash, please read the file
/home/robert/emacs/etc/DEBUG for instructions.


In GNU Emacs 23.1.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.1)
 of 2009-09-08 on robert-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.10600000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  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_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  desktop-save-mode: t
  recentf-mode: t
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

-- 
Robert A J Marshall,  
TNEI Services Ltd, 86-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
tel: +44 161 615 6017; fax: +44 161 615 6001; mobile: +44 7759 688384 
web: http://IPSA-Power.com 


[-- Attachment #3: Type: message/rfc822, Size: 1643 bytes --]

From: Robert Marshall <robert.marshall@tnei.co.uk>
To: 4375-done@emacsbugs.donarmstrong.com
Subject: Re: bug#4375: 23.1.50; can't kill killed gud buffer
Date: Thu, 10 Sep 2009 09:34:54 +0100
Message-ID: <4AA8BA2E.3020005@tnei.co.uk>

works for me! (thanks)

Robert

-- 
Robert A J Marshall,  
web: http://IPSA-Power.com