bug#28319: emacsclient tests interfere with running Emacs, hang

[Reuben Thomas <rrt@sc3d.org>]

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