unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#9839: compile with gdb running
       [not found] <N1B-Nk48Yzj02j@Safe-mail.net>
@ 2011-10-22 18:36 ` Glenn Morris
  2011-10-24 14:57   ` Adam
  0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-22 18:36 UTC (permalink / raw)
  To: adamw; +Cc: 9839


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?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-22 18:36 ` bug#9839: compile with gdb running Glenn Morris
@ 2011-10-24 14:57   ` Adam
  2011-10-24 17:03     ` Adam
  2011-10-24 17:21     ` Glenn Morris
  0 siblings, 2 replies; 15+ messages in thread
From: Adam @ 2011-10-24 14:57 UTC (permalink / raw)
  To: 9839

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?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-24 14:57   ` Adam
@ 2011-10-24 17:03     ` Adam
  2011-10-24 17:21     ` Glenn Morris
  1 sibling, 0 replies; 15+ messages in thread
From: Adam @ 2011-10-24 17:03 UTC (permalink / raw)
  To: 9839

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?





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-24 14:57   ` Adam
  2011-10-24 17:03     ` Adam
@ 2011-10-24 17:21     ` Glenn Morris
  2011-10-24 19:32       ` Glenn Morris
  1 sibling, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-24 17:21 UTC (permalink / raw)
  To: Adam; +Cc: 9839


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.






^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-24 17:21     ` Glenn Morris
@ 2011-10-24 19:32       ` Glenn Morris
  2011-10-24 19:53         ` Glenn Morris
  2011-10-25  1:58         ` Stefan Monnier
  0 siblings, 2 replies; 15+ messages in thread
From: Glenn Morris @ 2011-10-24 19:32 UTC (permalink / raw)
  To: Adam; +Cc: 9839, Nick Roberts

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-24 19:32       ` Glenn Morris
@ 2011-10-24 19:53         ` Glenn Morris
  2011-10-25  1:58         ` Stefan Monnier
  1 sibling, 0 replies; 15+ messages in thread
From: Glenn Morris @ 2011-10-24 19:53 UTC (permalink / raw)
  To: 9839


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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-24 19:32       ` Glenn Morris
  2011-10-24 19:53         ` Glenn Morris
@ 2011-10-25  1:58         ` Stefan Monnier
  2011-10-25  7:28           ` Glenn Morris
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2011-10-25  1:58 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9839, Adam, Nick Roberts

> 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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-25  1:58         ` Stefan Monnier
@ 2011-10-25  7:28           ` Glenn Morris
  2011-10-25 12:49             ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-25  7:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9839, Adam, Nick Roberts


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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-25  7:28           ` Glenn Morris
@ 2011-10-25 12:49             ` Stefan Monnier
  2011-10-25 16:30               ` Glenn Morris
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2011-10-25 12:49 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9839, Adam, Nick Roberts

> 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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-25 12:49             ` Stefan Monnier
@ 2011-10-25 16:30               ` Glenn Morris
  2011-10-25 20:15                 ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-25 16:30 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 9839, Adam, Nick Roberts

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-25 16:30               ` Glenn Morris
@ 2011-10-25 20:15                 ` Stefan Monnier
  2011-10-27 16:46                   ` Adam
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2011-10-25 20:15 UTC (permalink / raw)
  To: Glenn Morris; +Cc: 9839, Adam, Nick Roberts

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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-25 20:15                 ` Stefan Monnier
@ 2011-10-27 16:46                   ` Adam
  2011-10-27 18:49                     ` Glenn Morris
  0 siblings, 1 reply; 15+ messages in thread
From: Adam @ 2011-10-27 16:46 UTC (permalink / raw)
  To: 9839

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-27 16:46                   ` Adam
@ 2011-10-27 18:49                     ` Glenn Morris
  2011-10-29  0:13                       ` Glenn Morris
  0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-27 18:49 UTC (permalink / raw)
  To: 9839

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-27 18:49                     ` Glenn Morris
@ 2011-10-29  0:13                       ` Glenn Morris
  2011-10-30 13:13                         ` Adam
  0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2011-10-29  0:13 UTC (permalink / raw)
  To: 9839-done

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* bug#9839: compile with gdb running
  2011-10-29  0:13                       ` Glenn Morris
@ 2011-10-30 13:13                         ` Adam
  0 siblings, 0 replies; 15+ messages in thread
From: Adam @ 2011-10-30 13:13 UTC (permalink / raw)
  To: 9839

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!





^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2011-10-30 13:13 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <N1B-Nk48Yzj02j@Safe-mail.net>
2011-10-22 18:36 ` bug#9839: compile with gdb running Glenn Morris
2011-10-24 14:57   ` Adam
2011-10-24 17:03     ` Adam
2011-10-24 17:21     ` Glenn Morris
2011-10-24 19:32       ` Glenn Morris
2011-10-24 19:53         ` Glenn Morris
2011-10-25  1:58         ` Stefan Monnier
2011-10-25  7:28           ` Glenn Morris
2011-10-25 12:49             ` Stefan Monnier
2011-10-25 16:30               ` Glenn Morris
2011-10-25 20:15                 ` Stefan Monnier
2011-10-27 16:46                   ` Adam
2011-10-27 18:49                     ` Glenn Morris
2011-10-29  0:13                       ` Glenn Morris
2011-10-30 13:13                         ` Adam

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).