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

[Eli Zaretskii <eliz@gnu.org>]

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