* 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
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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.