From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32335 invoked by alias); 19 Oct 2017 04:01:51 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 32322 invoked by uid 89); 19 Oct 2017 04:01:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=talk, spend X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Oct 2017 04:01:49 +0000 Received: by mail-wm0-f49.google.com with SMTP id q132so13640358wmd.2 for ; Wed, 18 Oct 2017 21:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lZWNqA9qT5B8I78KnUCW3bmNYt3s2ocSS51vzsu6C+4=; b=ca3fnL0vp++vStv5ZouhkQz3dqlo9NN+mOWohgBuS7FwhRvb7sqe+qSAokqUDuieeB 737HNPDTklg0tlX+bHQnNGg9A3g4iVNBVKwQl+eZg4EjFq1YhDptgCs60oq63IQ5qOvT vNgtv/T3ZM2VhM57BFzUWDwf1kqu9s4yQz/8Se1Whrf44+szhuCTPh6YNijs12LA4lZF 0KVbHroanyvmuqa9XBzmq+ZxnqlsErFUhLnbmhKvO//9gn0aJeEPGoPtTm9jGxpgl1xC ebCkrCCT2U0H4k7i7PAljlJ50qQF6SZUeUrgI1sC4xyyNoRMWIZh6bQM+OQFoXM+9DEL ei/g== X-Gm-Message-State: AMCzsaUT/GWkurU7rO7RgPOGCkuil/ydHyviMxGW1GL6129qDaY1M8M9 BG8t7Z7QVTcPGBM9XgU9kXC5BFnI9R4LbEvtKQ== X-Google-Smtp-Source: ABhQp+R3zy77+3qcbHsiDy8Lvydb5ZqJpmrovHgalTg/JbTlFKNRZ3Ip6LtRKXVFcBvfA9OPB2SxHwjBl0W9n39/cNM= X-Received: by 10.80.241.155 with SMTP id x27mr691404edl.119.1508385707686; Wed, 18 Oct 2017 21:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.174.36 with HTTP; Wed, 18 Oct 2017 21:01:47 -0700 (PDT) In-Reply-To: <09d0a9e5-e1af-f0e1-ab2b-11d33b453145@redhat.com> References: <09d0a9e5-e1af-f0e1-ab2b-11d33b453145@redhat.com> From: Yubin Ruan Date: Thu, 19 Oct 2017 04:01:00 -0000 Message-ID: Subject: Re: determine whether code is running in a signal handler context To: "Carlos O'Donell" Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg00022.txt.bz2 Hi Carlos, 2017-10-19 10:19 GMT+08:00 Carlos O'Donell : > On 10/18/2017 06:52 PM, Yubin Ruan wrote: >> 2017-10-19 2:34 GMT+08:00 Carlos O'Donell : >>> On 10/18/2017 07:18 AM, Yubin Ruan wrote: >>>> Hi, >>>> >>>> I am writing to see if this is any util functions in libc that can >>>> help to determine it is currently running in a signal. >>>> >>>> I wrote some library and provide a function which will be used in many >>>> client code. However this function is not async-signal safe (it calls >>>> malloc(3)) so when it is called, I want to detect whether it is >>>> currently running in a signal handler. If it is, I can avoid calling >>>> those not-async-signal-safe functions which might cause deadlock. >>>> >>>> that is, I want a `in_signal_handler_context()' utility that can be >>>> used as this: >>>> >>>> int mylibfunc( void ) { >>>> if( in_signal_handler_context() ) { return(-1) } >>>> // rest of function goes here >>>> return( 0 ); >>>> } >>> >>> Only (b). >>> >>> (a) The kernel knows, but doesn't tell you. >>> >>> (b) Only via architecture-specific checks which involve inspecting the >>> call frame to determine if there is a signal frame on the stack. >> >> Is (b) deterministic? How can we know whether a call frame is a signal >> frame and how can we know at which point we should stop when >> inspecting the frame? > > We could spend days talking about this. The answer should be deterministic, > and gdb solves it, but the solution involves some heuristic checks, and > unwinding (a complex topic). So I think I am going to talk with some gdb people some more. >> Somebody pointed out that on Linux all signal handlers are called from >> vdso, so I come up with the following code to "inspect" the call frame >> and see whether there is any address which points at some place inside >> the VDSO: > > This is not true. It is architecture dependent. For examples on how complex > it is to get this 100% right you have to go read gdb sources to see how > they do this. It is non-trivial. It might be easier to use a library like > libunwind to determine this for you (if it even can). Will it be better if we can limit the architecture to X86/64? Yubin