bug#9839: compile with gdb running

bug#9839: compile with gdb running

[Glenn Morris]

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?

bug#9839: compile with gdb running

[Adam]

Glenn Morris <rgm@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?

bug#9839: compile with gdb running

[Adam]

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

Adam <adam_w67@yahoo.com> writes:

> Glenn Morris <rgm@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?

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Glenn Morris]

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...

bug#9839: compile with gdb running

[Stefan Monnier]

> 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

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Stefan Monnier]

> 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

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Stefan Monnier]

>> 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

bug#9839: compile with gdb running

[Adam]

Stefan Monnier <monnier@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.

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Glenn Morris]

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.

bug#9839: compile with gdb running

[Adam]

Glenn Morris <rgm@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!