public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Tom Tromey <tom@tromey.com>, Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix gdb crash due to SIGPIPE when the compile command fails
Date: Tue, 15 Jun 2021 00:35:16 +0100	[thread overview]
Message-ID: <6256676d-b41a-02ef-22a4-e5150077c0e8@palves.net> (raw)
In-Reply-To: <87zgw5oijf.fsf@tromey.com>

On 2021-06-04 2:39 p.m., Tom Tromey wrote:
>>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> 
> Bernd> I believe it is right to avoid the SIGPIPE before calling the plugin,
> Bernd> instead of doing that in gcc-trunk, since we don't know which version
> Bernd> we will be calling, and all versions I tried have failed like this.
> 
> That seems fine, but I think it would be better to install the handler
> just when working with the plugin, and then uninstall it afterward, sort
> of like what class scoped_ignore_sigttou does.

One thing I dislike here (and also about scoped_ignore_sigttou), is that the
signal disposition is process-wide.  

If we happen to have multiple threads that need to ignore the signal changing the
disposition like that, then they may race.

We can fix that by making the ignoring be per-thread instead by using
sigprocmask + sigtimedwait.  

We can also introduce a generic scoped_ignore_signal so that both scoped_ignore_sigttou
and scoped_ignore_pipe (and whatever other similar signal we may need to ignore) share
the same code.  

I gave it a quick try.  See the 4 patches at the top of the
users/palves/scoped_ignore_signal branch.

This was something that I've thought before about doing for SIGTTOU to be honest.
Seeing it being copied over to SIGPIPE was simply the trigger that made me
actually give it a try.  

WDYT?

Pedro Alves

  parent reply	other threads:[~2021-06-14 23:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 17:31 Bernd Edlinger
2021-06-02 18:21 ` Tom Tromey
2021-06-02 22:19   ` Christian Biesinger
2021-06-03  5:45     ` Bernd Edlinger
2021-06-04 13:39       ` Tom Tromey
2021-06-05 11:44         ` Bernd Edlinger
2021-06-05 12:04           ` Andrew Burgess
2021-06-05 12:27             ` Bernd Edlinger
2021-06-05 14:04               ` Tom Tromey
2021-06-14 11:41           ` Rainer Orth
2021-06-14 12:57             ` Bernd Edlinger
2021-06-14 12:59               ` Rainer Orth
2021-06-14 14:36                 ` Bernd Edlinger
2021-06-14 14:39                   ` Rainer Orth
2021-06-14 15:07                 ` Tom Tromey
2021-06-15 11:10                   ` Rainer Orth
2021-06-14 15:04               ` Tom Tromey
2021-06-14 23:35         ` Pedro Alves [this message]
2021-06-15  5:14           ` Bernd Edlinger
2021-06-15 11:16             ` Pedro Alves

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=6256676d-b41a-02ef-22a4-e5150077c0e8@palves.net \
    --to=pedro@palves.net \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /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.
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).