unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: John Mellor-Crummey via Libc-alpha <libc-alpha@sourceware.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, Xiaozhu Meng <xm13@rice.edu>,
	John Mellor-Crummey <johnmc@rice.edu>,
	"Mark W. Krentel" <krentel@rice.edu>
Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list)
Date: Tue, 22 Jun 2021 11:17:15 -0500	[thread overview]
Message-ID: <8055B154-337B-4B30-9036-056AB5750766@rice.edu> (raw)
In-Reply-To: <87o8bxdi8b.fsf@oldenburg.str.redhat.com>

Florian,


> On Jun 22, 2021, at 10:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * John Mellor-Crummey:
> 
>>> On Jun 22, 2021, at 3:15 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> You can already see this non-interceptable thread creation behavior
>>> today (in glibc 2.33 and earlier) with thrd_create, which does not
>>> result in a pthread_create call, either, despite creating a new thread
>>> as if by pthread_create.
>> 
>> Having a non-interposable thrd_create is a problem for us too, though 
>> we haven’t yet seen it in practice in HPC applications (or maybe it happened
>> and we were just unaware!).
> 
> I meant that thrd_create needs to be intercepted separately.  This will
> still work.

Got it.

Would you recommend intercepting clone instead of trying
to intercept pthread_create and thrd_create?

That should avoid trouble interposing pthread_create.

> 
>>> Going back to trheading, I find it a bit curious that you intercept
>>> pthread_create, but not pthread_join.  How do you detect thread exit?  I
>>> assume you are interested in that event, too.  Merely wrapping the
>>> thread start routine is insufficient because there are other ways for a
>>> thread to exit besides returning from the start routine and calling
>>> pthread_exit (e.g., thread cancellation and unwinding).
>> 
>> We use pthread_cleanup_push to add a routine that will be called when a thread
>> exits.
> 
> Okay, that should work, although some application-supplied TLS
> destructors will run later than that.

For our tools, we need to shut down profiling when a thread is finishing. That
can and should be done before the thread really gets torn down. We have
learned the hard way that we need to turn off profiling before TLS destruction starts. 

--
John Mellor-Crummey		Professor
Dept of Computer Science	Rice University
email: johnmc@rice.edu		phone: 713-348-5179


  reply	other threads:[~2021-06-22 16:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 17:55 A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) John Mellor-Crummey via Libc-alpha
2021-06-17 19:42 ` Adhemerval Zanella via Libc-alpha
2021-06-17 20:09   ` Florian Weimer via Libc-alpha
2021-06-17 23:06     ` Adhemerval Zanella via Libc-alpha
2021-06-23 17:42       ` Ben Woodard via Libc-alpha
2021-07-30 14:58         ` Adhemerval Zanella via Libc-alpha
2021-07-30 18:59           ` Ben Woodard via Libc-alpha
2021-07-30 21:09             ` Adhemerval Zanella via Libc-alpha
2021-07-31  0:59               ` Ben Woodard via Libc-alpha
2021-08-04 18:11                 ` Adhemerval Zanella via Libc-alpha
2021-08-05 10:32                   ` Szabolcs Nagy via Libc-alpha
2021-08-05 19:36                     ` Ben Woodard via Libc-alpha
2021-08-06  9:04                       ` Szabolcs Nagy via Libc-alpha
2021-06-21 19:42     ` John Mellor-Crummey via Libc-alpha
2021-06-22  8:15       ` Florian Weimer via Libc-alpha
2021-06-22 15:04         ` John Mellor-Crummey via Libc-alpha
2021-06-22 15:36           ` Florian Weimer via Libc-alpha
2021-06-22 16:17             ` John Mellor-Crummey via Libc-alpha [this message]
2021-06-22 16:33               ` Adhemerval Zanella via Libc-alpha
2021-06-23  6:32                 ` Florian Weimer via Libc-alpha
2021-06-23 20:06                   ` Mark Krentel via Libc-alpha
2021-06-18 17:48   ` John Mellor-Crummey via Libc-alpha
2021-06-18 18:27     ` Adhemerval Zanella via Libc-alpha

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

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8055B154-337B-4B30-9036-056AB5750766@rice.edu \
    --to=libc-alpha@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=johnmc@rice.edu \
    --cc=krentel@rice.edu \
    --cc=xm13@rice.edu \
    /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).