From: Eli Zaretskii <eliz@gnu.org>
To: Reuben Thomas <rrt@sc3d.org>
Cc: 28319@debbugs.gnu.org
Subject: bug#28319: emacsclient tests interfere with running Emacs, hang
Date: Wed, 06 Sep 2017 19:02:09 +0300 [thread overview]
Message-ID: <83pob324u6.fsf@gnu.org> (raw)
In-Reply-To: <CAOnWdojxodtc2pQahsseO0FRysXQeKiQ-A22X=rgT5WKB8vWQQ@mail.gmail.com> (message from Reuben Thomas on Tue, 5 Sep 2017 22:11:15 +0100)
> 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.
next prev parent reply other threads:[~2017-09-06 16:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2017-09-07 23:10 ` Reuben Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83pob324u6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=28319@debbugs.gnu.org \
--cc=rrt@sc3d.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.