* bug#28319: emacsclient tests interfere with running Emacs, hang
@ 2017-09-01 16:40 Glenn Morris
2017-09-01 17:23 ` Reuben Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2017-09-01 16:40 UTC (permalink / raw)
To: 28319; +Cc: rrt
Package: emacs
Version: 26.0.50
The emacsclient tests added in 98f01a1 fail on hydra, ref eg
https://hydra.nixos.org/build/59905042
(wrong-type-argument number-or-marker-p "Profiling timer expired")
On my own desktop machine, they also fail, and interfere with my normal
editing Emacs:
Have an Emacs session open, with an active server.
Run make lib-src/emacsclient-tests
This pops up a "foo" buffer in my desktop Emacs.
The tests now hang and do not return.
The emacsclient process is not killed.
The tests should use their own dedicated server, with a timeout.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-01 16:40 bug#28319: emacsclient tests interfere with running Emacs, hang Glenn Morris
@ 2017-09-01 17:23 ` Reuben Thomas
2017-09-01 20:37 ` Reuben Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Reuben Thomas @ 2017-09-01 17:23 UTC (permalink / raw)
To: Glenn Morris; +Cc: 28319
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
On 1 September 2017 at 17:40, Glenn Morris <rgm@gnu.org> wrote:
> Package: emacs
> Version: 26.0.50
>
> The emacsclient tests added in 98f01a1 fail on hydra, ref eg
>
> https://hydra.nixos.org/build/59905042
> (wrong-type-argument number-or-marker-p "Profiling timer expired")
>
> On my own desktop machine, they also fail, and interfere with my normal
> editing Emacs:
>
> Have an Emacs session open, with an active server.
> Run make lib-src/emacsclient-tests
> This pops up a "foo" buffer in my desktop Emacs.
> The tests now hang and do not return.
> The emacsclient process is not killed.
>
> The tests should use their own dedicated server, with a timeout.
>
Sorry about this, I was aware of the problem while developing the tests,
but forgot to address it before committing the patch.
In fact, the current tests do not require a server: the whole point is to
test the ALTERNATE_EDITOR variable, when the server cannot be contacted.
So, I guess I can fix this by running emacsclient as something like
emacsclient -f /file/does/not/exist
? I can't find any other tests that use emacsclient or run a server (as I
couldn't before when I looked for a model), so I'd appreciate knowing
whether there are any obvious problems with this strategy before I try it.
Obviously, if more emacsclient tests were written in future which did not
rely on immediate exit, they would need, as you say, a dedicated server.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
[-- Attachment #2: Type: text/html, Size: 2541 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-01 17:23 ` Reuben Thomas
@ 2017-09-01 20:37 ` Reuben Thomas
2017-09-01 22:19 ` Glenn Morris
0 siblings, 1 reply; 11+ messages in thread
From: Reuben Thomas @ 2017-09-01 20:37 UTC (permalink / raw)
To: Glenn Morris; +Cc: 28319
[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]
On 1 September 2017 at 18:23, Reuben Thomas <rrt@sc3d.org> wrote:
> On 1 September 2017 at 17:40, Glenn Morris <rgm@gnu.org> wrote:
>
>> Package: emacs
>> Version: 26.0.50
>>
>> The emacsclient tests added in 98f01a1 fail on hydra, ref eg
>>
>> https://hydra.nixos.org/build/59905042
>> (wrong-type-argument number-or-marker-p "Profiling timer expired")
>>
>> On my own desktop machine, they also fail, and interfere with my normal
>> editing Emacs:
>>
>> Have an Emacs session open, with an active server.
>> Run make lib-src/emacsclient-tests
>> This pops up a "foo" buffer in my desktop Emacs.
>> The tests now hang and do not return.
>> The emacsclient process is not killed.
>>
>> The tests should use their own dedicated server, with a timeout.
>>
>
> Sorry about this, I was aware of the problem while developing the tests,
> but forgot to address it before committing the patch.
>
> In fact, the current tests do not require a server: the whole point is to
> test the ALTERNATE_EDITOR variable, when the server cannot be contacted.
> So, I guess I can fix this by running emacsclient as something like
>
> emacsclient -f /file/does/not/exist
>
> ? I can't find any other tests that use emacsclient or run a server (as I
> couldn't before when I looked for a model), so I'd appreciate knowing
> whether there are any obvious problems with this strategy before I try it.
> Obviously, if more emacsclient tests were written in future which did not
> rely on immediate exit, they would need, as you say, a dedicated server.
>
I have pushed 4bc2795 to address this. I'll keep an eye on how the hydra
build turns out.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
[-- Attachment #2: Type: text/html, Size: 3005 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-01 20:37 ` Reuben Thomas
@ 2017-09-01 22:19 ` Glenn Morris
2017-09-01 22:44 ` Reuben Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2017-09-01 22:19 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 28319
Thanks. BTW:
1. (let (process-environment process-environment) doesn't look right?
"((process-environment process-environment))" or "(process-environment)"?
2. I don't know if we care about obeying naming prefix conventions in
test files. I guess probably yes? In which case "call-emacsclient"
should be renamed.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-01 22:19 ` Glenn Morris
@ 2017-09-01 22:44 ` Reuben Thomas
2017-09-05 19:55 ` Glenn Morris
0 siblings, 1 reply; 11+ messages in thread
From: Reuben Thomas @ 2017-09-01 22:44 UTC (permalink / raw)
To: Glenn Morris; +Cc: 28319
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
On 1 September 2017 at 23:19, Glenn Morris <rgm@gnu.org> wrote:
>
> Thanks. BTW:
>
> 1. (let (process-environment process-environment) doesn't look right?
> "((process-environment process-environment))" or "(process-environment)"?
>
> 2. I don't know if we care about obeying naming prefix conventions in
> test files. I guess probably yes? In which case "call-emacsclient"
> should be renamed.
>
Thanks, I've fixed both of these, plus a similar incidence to 2 in a
different test from which I think I copied the code originally.
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
[-- Attachment #2: Type: text/html, Size: 1195 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-01 22:44 ` Reuben Thomas
@ 2017-09-05 19:55 ` Glenn Morris
2017-09-05 21:11 ` Reuben Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2017-09-05 19:55 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 28319
The tests still fail on hydra with "Profiling timer expired".
I can reproduce this locally if I configure with --enable-profiling.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-05 19:55 ` Glenn Morris
@ 2017-09-05 21:11 ` Reuben Thomas
2017-09-05 22:24 ` Glenn Morris
2017-09-06 16:02 ` Eli Zaretskii
0 siblings, 2 replies; 11+ messages in thread
From: Reuben Thomas @ 2017-09-05 21:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: 28319
[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]
On 5 September 2017 at 20:55, Glenn Morris <rgm@gnu.org> wrote:
>
> The tests still fail on hydra with "Profiling timer expired".
> I can reproduce this locally if I configure with --enable-profiling.
>
Thanks for the reproduction method, and for the tidy-up work you did on
the tests; I can reproduce the "timer expired" problem.
I see that --enable-profiling stops profiler.el from working, so it's
nothing to do with profiler.el (this suggests incidentally that there's
nothing I can do directly about the problem from Elisp, hence in the test
code itself). I also see that the error message "Profiling timer expired"
is caused by SIGPROF. Looking at the code in Emacs controlled by
-DPROFILING (set to 1 by --enable-profiling), I find there's very little,
but what there is seems to refer to the mon* routines, for which I find no
man pages on my system, but a little searching online suggests are
BSD-derived.
I see that Emacs, in src/sysdep.c, sets SIGPROF's handler to SIG_IGN. So
Emacs ignores the signal, but clearly from the call-process return value,
it's being delivered to the emacsclient child process.
The main thing I don't understand is why this behavior isn't a problem for
other tests that use call-process, except that they don't seem to check the
return value; but unlike the emacsclient test, at least some of them rely
on some action having been taken by the called process, so presumably it
must have completed successfully before receiving SIGPROF? If this is
indeed the case, then the emacsclient test could simply allow the error
message to signal success.
Can you enlighten me any further?
--
https://rrt.sc3d.org <http://rrt.sc3d.org>
[-- Attachment #2: Type: text/html, Size: 2542 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-05 21:11 ` Reuben Thomas
@ 2017-09-05 22:24 ` Glenn Morris
2017-09-06 1:14 ` Glenn Morris
2017-09-06 16:02 ` Eli Zaretskii
1 sibling, 1 reply; 11+ messages in thread
From: Glenn Morris @ 2017-09-05 22:24 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 28319
Reuben Thomas wrote:
> The main thing I don't understand is why this behavior isn't a problem for
> other tests that use call-process, except that they don't seem to check the
> return value;
They do use the return value, eg info-xref-test-write-file.
I think it is something specific to emacsclient when compiled with "-pg".
(But I don't really know anything about this.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-05 21:11 ` Reuben Thomas
2017-09-05 22:24 ` Glenn Morris
@ 2017-09-06 16:02 ` Eli Zaretskii
2017-09-07 23:10 ` Reuben Thomas
1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2017-09-06 16:02 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 28319
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 5 Sep 2017 22:11:15 +0100
> Cc: 28319@debbugs.gnu.org
>
> I see that Emacs, in src/sysdep.c, sets SIGPROF's handler to SIG_IGN. So Emacs ignores the signal, but
> clearly from the call-process return value, it's being delivered to the emacsclient child process.
What Emacs does in sysdep.c doesn't sound relevant, as the problem
happens also when only emacsclient is built with -pg. So I think
SIGPROF that matters happens in emacsclient, not in Emacs.
> The main thing I don't understand is why this behavior isn't a problem for other tests that use call-process,
Most probably because the programs they invoke aren't built with -pg.
> except that they don't seem to check the return value; but unlike the emacsclient test, at least some of them
> rely on some action having been taken by the called process, so presumably it must have completed
> successfully before receiving SIGPROF? If this is indeed the case, then the emacsclient test could simply
> allow the error message to signal success.
>
> Can you enlighten me any further?
Could it be that SIGPROF triggered by the profiling code interrupts
some system call made by emacsclient, and emacsclient doesn't have
code to recover from that?
In any case, why are we running the test suite with Emacs compiled
with profiling? Is there a good reason for doing that? Does that
bring us some useful data? If not, simply building without profiling
might easily fix this problem.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#28319: emacsclient tests interfere with running Emacs, hang
2017-09-06 16:02 ` Eli Zaretskii
@ 2017-09-07 23:10 ` Reuben Thomas
0 siblings, 0 replies; 11+ messages in thread
From: Reuben Thomas @ 2017-09-07 23:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 28319
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On 6 September 2017 at 17:02, Eli Zaretskii <eliz@gnu.org> wrote:
>
> In any case, why are we running the test suite with Emacs compiled
> with profiling? Is there a good reason for doing that? Does that
> bring us some useful data? If not, simply building without profiling
> might easily fix this problem.
>
Nonetheless, it should be possible to run the test suite when building
with --enable-profiling.
However, it's not obvious that profiling is of great interest for the
programs in lib-src, so an option would be to change the build system so
that --enable-profiling applies only to emacs itself. This would obviate
potential similar problems testing other lib-src binaries in future.
--
https://rrt.sc3d.org
[-- Attachment #2: Type: text/html, Size: 1456 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-09-07 23:10 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-01 16:40 bug#28319: emacsclient tests interfere with running Emacs, hang Glenn Morris
2017-09-01 17:23 ` Reuben Thomas
2017-09-01 20:37 ` Reuben Thomas
2017-09-01 22:19 ` Glenn Morris
2017-09-01 22:44 ` Reuben Thomas
2017-09-05 19:55 ` Glenn Morris
2017-09-05 21:11 ` Reuben Thomas
2017-09-05 22:24 ` Glenn Morris
2017-09-06 1:14 ` Glenn Morris
2017-09-06 16:02 ` Eli Zaretskii
2017-09-07 23:10 ` Reuben Thomas
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).