GNU bug report logs - #9839
compile with gdb running

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 9839 in the body.
You can then email your comments to 9839 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: adamw <at> Safe-mail.net
To: help-gnu-emacs <at> gnu.org, bug-gnu-emacs <at> gnu.org
Subject: compile with gdb running
Date: Sat, 22 Oct 2011 14:25:19 -0400

I am using emacs pretest on GNU/Linux. I stumbled upon an interesting behaviour today. How to reproduce:

emacs -q
M-x gdb RET ls RET
r
# at this point gdb is starting ls
M-x compile RET

The compile buffer pops up, but there is not the 

"make: *** No targets specified and no makefile found.  Stop.
Compilation exited abnormally ..."-

output.

Is this a bug? If so, how can I work around it?

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

From: Glenn Morris <rgm <at> gnu.org>
To: adamw <at> Safe-mail.net
Cc: 9839 <at> debbugs.gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Sat, 22 Oct 2011 14:36:11 -0400

Please don't cross-post to the help and bug lists, just pick one.
Hopefully I have managed to arrange it so that your report only appears
on the bug list.

Here is the report so that others can see it:

    I am using emacs pretest on GNU/Linux. I stumbled upon an interesting
    behaviour today. How to reproduce:

    emacs -q
    M-x gdb RET ls RET
    r
    # at this point gdb is starting ls
    M-x compile RET

    The compile buffer pops up, but there is not the 

    "make: *** No targets specified and no makefile found.  Stop.
    Compilation exited abnormally ..."-

    output.

    Is this a bug? If so, how can I work around it?

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

From: Adam <adam_w67 <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 16:57:38 +0200

Glenn Morris <rgm <at> gnu.org> writes:

I investigated a little.  Somehow the call to the process sentinel
(compilation-sentinel) is delayed until the gdb process is quit.

Unfortunately I lack the understanding of Emacs internals to debug this
annoying issue further.

> Please don't cross-post to the help and bug lists, just pick one.
> Hopefully I have managed to arrange it so that your report only
> appears on the bug list.
>
> Here is the report so that others can see it:
>
>     I am using emacs pretest on GNU/Linux. I stumbled upon an
>     interesting behaviour today. How to reproduce:
>
>     emacs -q
>     M-x gdb RET ls RET
>     r
>     # at this point gdb is starting ls
>     M-x compile RET
>
>     The compile buffer pops up, but there is not the
>
>     "make: *** No targets specified and no makefile found.  Stop.
>     Compilation exited abnormally ..."-
>
>     output.
>
>     Is this a bug? If so, how can I work around it?

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

From: Adam <adam_w67 <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 19:03:01 +0200

Yet another pointer: M-x gud-gdb and compilation works fine.  AFAICT
this issue roots in gdb-mi.el

Adam <adam_w67 <at> yahoo.com> writes:

> Glenn Morris <rgm <at> gnu.org> writes:
>
> I investigated a little.  Somehow the call to the process sentinel
> (compilation-sentinel) is delayed until the gdb process is quit.
>
> Unfortunately I lack the understanding of Emacs internals to debug this
> annoying issue further.
>
>> Please don't cross-post to the help and bug lists, just pick one.
>> Hopefully I have managed to arrange it so that your report only
>> appears on the bug list.
>>
>> Here is the report so that others can see it:
>>
>>     I am using emacs pretest on GNU/Linux. I stumbled upon an
>>     interesting behaviour today. How to reproduce:
>>
>>     emacs -q
>>     M-x gdb RET ls RET
>>     r
>>     # at this point gdb is starting ls
>>     M-x compile RET
>>
>>     The compile buffer pops up, but there is not the
>>
>>     "make: *** No targets specified and no makefile found.  Stop.
>>     Compilation exited abnormally ..."-
>>
>>     output.
>>
>>     Is this a bug? If so, how can I work around it?

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

From: Glenn Morris <rgm <at> gnu.org>
To: Adam <adam_w67 <at> yahoo.com>
Cc: 9839 <at> debbugs.gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 13:21:59 -0400

Fo me, simply running

emacs -Q
M-x gdb RET gdb -i=mi ls RET
r RET

causes Emacs to start using 100% of CPU (but still be usable).
This happens on two different systems.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Adam <adam_w67 <at> yahoo.com>
Cc: 9839 <at> debbugs.gnu.org, Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 15:32:26 -0400

Glenn Morris wrote:

> Fo me, simply running
>
> emacs -Q
> M-x gdb RET gdb -i=mi ls RET
> r RET
>
> causes Emacs to start using 100% of CPU (but still be usable).
> This happens on two different systems.

Sounds like my problem is

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4545

which is also

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5145

Applying the suggestion from

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5145#10

fixes both my problem and yours AFAICS.

So it seems M-x gdb in Emacs has not been working right for a couple of
years, which is a shame.

I am merging all these bugs and raising the severity.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 9839 <at> debbugs.gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 15:53:25 -0400

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4437
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6623
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6962
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9720

might all be related as well.

I hope someone who knows about process.c could look at this...

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9839 <at> debbugs.gnu.org, Adam <adam_w67 <at> yahoo.com>,
	Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Mon, 24 Oct 2011 21:58:55 -0400

> Applying the suggestion from
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5145#10

In the absence of any answer from Nick about it, I think the best option
is to revert that change.


        Stefan

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9839 <at> debbugs.gnu.org, Adam <adam_w67 <at> yahoo.com>,
	Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Tue, 25 Oct 2011 03:28:31 -0400

A comment about the change in question is given in

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4437#30

    This allows the I/O buffer to work when the inferior is restarted
    but means that status_notify isn't called from
    wait_reading_process_output because this call is conditioned on
    select which returns a positive value (presumably because the pty's
    file descriptor hasn't been cleared). Reverting it means processes
    aren't left lying around but that leaves the original problem.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9839 <at> debbugs.gnu.org, Adam <adam_w67 <at> yahoo.com>,
	Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Tue, 25 Oct 2011 08:49:08 -0400

> A comment about the change in question is given in

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4437#30

>     This allows the I/O buffer to work when the inferior is restarted
>     but means that status_notify isn't called from
>     wait_reading_process_output because this call is conditioned on
>     select which returns a positive value (presumably because the pty's
>     file descriptor hasn't been cleared). Reverting it means processes
>     aren't left lying around but that leaves the original problem.

I don't understand what "allows the I/O buffer to work when the inferior
is restarted" means.


        Stefan

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9839 <at> debbugs.gnu.org, Adam <adam_w67 <at> yahoo.com>,
	Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Tue, 25 Oct 2011 12:30:05 -0400

Stefan Monnier wrote:

> I don't understand what "allows the I/O buffer to work when the inferior
> is restarted" means.

No, me neither. :) The ChangeLog says it slightly differently:

   * process.c (wait_reading_process_output): Keep the descriptor
   when pty is used by a non-child process, e.g., in I/O buffer of
   GDB this allows inferior to be restarted.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9839 <at> debbugs.gnu.org, Adam <adam_w67 <at> yahoo.com>,
	Nick Roberts <nickrob <at> gnu.org>
Subject: Re: bug#9839: compile with gdb running
Date: Tue, 25 Oct 2011 16:15:50 -0400

>> I don't understand what "allows the I/O buffer to work when the inferior
>> is restarted" means.
> No, me neither. :) The ChangeLog says it slightly differently:
>    * process.c (wait_reading_process_output): Keep the descriptor
>    when pty is used by a non-child process, e.g., in I/O buffer of
>    GDB this allows inferior to be restarted.

I saw that as well, but it doesn't help me understand.  I strongly
suspect that the real problem was elsewhere.  Let's revert this change
and see what breaks so we can try and fix it "right".


        Stefan

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

From: Adam <adam_w67 <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Thu, 27 Oct 2011 18:46:57 +0200

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

>>> I don't understand what "allows the I/O buffer to work when the inferior
>>> is restarted" means.
>> No, me neither. :) The ChangeLog says it slightly differently:
>>    * process.c (wait_reading_process_output): Keep the descriptor
>>    when pty is used by a non-child process, e.g., in I/O buffer of
>>    GDB this allows inferior to be restarted.
>
> I saw that as well, but it doesn't help me understand.  I strongly
> suspect that the real problem was elsewhere.  Let's revert this change
> and see what breaks so we can try and fix it "right".

ping?  I am still experiencing my problem with today's trunk.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 9839 <at> debbugs.gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Thu, 27 Oct 2011 14:49:11 -0400

Adam wrote:

> ping?  I am still experiencing my problem with today's trunk.

That's because nothing has changed.
I will be applying the relevant change in a few days, before the next
pretest, if there are no further comments before then.

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

From: Glenn Morris <rgm <at> gnu.org>
To: 9839-done <at> debbugs.gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Fri, 28 Oct 2011 20:13:48 -0400

Version: 24.0.91

The 2009-08-30 change to process.c has been reverted, so this should be
fixed now in the Emacs trunk, and in the coming 24.0.91 pretest.

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

From: Adam <adam_w67 <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9839: compile with gdb running
Date: Sun, 30 Oct 2011 14:13:37 +0100

Glenn Morris <rgm <at> gnu.org> writes:

> Version: 24.0.91
>
> The 2009-08-30 change to process.c has been reverted, so this should
> be fixed now in the Emacs trunk, and in the coming 24.0.91 pretest.

Fixed.  Thank you!

Previous Next

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