From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94783 invoked by alias); 7 Sep 2016 19:22:52 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 94769 invoked by uid 89); 7 Sep 2016 19:22:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=dare, imagined, love, documents X-HELO: mail-it0-f54.google.com Received: from mail-it0-f54.google.com (HELO mail-it0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Sep 2016 19:22:42 +0000 Received: by mail-it0-f54.google.com with SMTP id c198so40425609ith.1 for ; Wed, 07 Sep 2016 12:22:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=472EA5n0HhXzUU5LLJ27FcpckvtWkxZDhirOfpug1bg=; b=bK+BUIeJDiguR6NbMV0S3PB8B0m7v76t/IGianltJgFt5E5NBBnhpLfZE3lGfCOj5c LkSlPyBO2vRuOWzFQKLWcSwKdgPGlQxHj64umaApxZ7kFIZegU7sUt6MW3zomdjcQIqx mHd9jDHN+i0OeHeOGN9Fh/gK5dAqcK0VuIHnmzr+9+FZav5F11U/wlUK/eNCaS+65CPj 0w8QgHPuuPacaexVeqbAtsweYFSSnW3B7KlvxkF5KhAZ5DGnC1OMMRfD7e8X5wgYo6+e ofb52FHAm7sFnqM/HTjCrmCtK+odQM4hGdg+vRTlH6UO6BRpNGgs1PCEHF0zQNGYrHk5 7S4A== X-Gm-Message-State: AE9vXwP7oYSwVINwX73PYyUj+sDa+yc8rhcwI7MJsy5szqjspGexgg4p70r8qdqJubJf2JKEY9NxqdI0Y3b2AQ== X-Received: by 10.36.129.193 with SMTP id q184mr8711649itd.35.1473276160285; Wed, 07 Sep 2016 12:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.34.141 with HTTP; Wed, 7 Sep 2016 12:22:39 -0700 (PDT) In-Reply-To: References: <87b59611-f5d1-628d-fd41-85ce6c6eb50b@samersoff.net> From: Samuel Bronson Date: Wed, 07 Sep 2016 19:22:00 -0000 Message-ID: Subject: Re: collecting data from a coring process To: Paul Marquess Cc: Dmitry Samersoff , vijay nag , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00043.txt.bz2 On Tue, Sep 6, 2016 at 12:40 PM, Paul Marquess wrote: > From: Samuel Bronson [mailto:naesten@gmail.com] > > >> On Mon, Sep 5, 2016 at 7:19 PM, Paul Marquess wrote: >> > From: Samuel Bronson [mailto:naesten@gmail.com] >> > >> >> On Mon, Sep 5, 2016 at 7:09 AM, Paul Marquess wrote: >> >> > From: Dmitry Samersoff [mailto:dms@samersoff.net] >> >> > >> >> >> Paul, >> >> >> >> >> >> >> 1) Why not dump the information that you are looking for into a >> >> >> >> file in the process signal handler ? >> >> >> > >> >> >> > Would love to, but I have no idea what state the process is in >> >> >> > once the SEGV has been triggered. >> >> [...] >> >> > I know we've had problems with signal handlers causing problems, th= us my preference to find a way to have the signal handler code do as little= as possible and get all the data collection handled at arm's length by gdb. >> >> >> >> You could just spawn (and wait for) your GDB-launching script from >> >> the signal handler; then, the process & stack will still be around fo= r GDB. I think this is even legal! >> > >> > That's one of the approaches I'm thinking of. I need to check if the f= ork/exec & wait use malloc. >> >> I think it should suffice for them to be "async-signal-safe "? It looks= like signal(7) documents which functions several >> versions of POSIX require to be async-signal-safe, and it looks like the= re are two versions of exec*() on there as well >> as fork() and wait(). Which is basically what I meant by "I think this = is even legal!" :-). > > I agree that "async-signal-safe " is something that needs to be considere= d, but it isn't the only thing. I've seen plenty of cores where corruption = of a data structure inside malloc itself was the trigger for the SEGV. That= 's why I need to be sure that any code executed in the signal handler isn't= going to blow up. Hmm. I had not really considered that it might technically be possible to have an async-signal-safe implementation of malloc(), and was therefore operating under the assumption that it was impossible for an async-signal-safe function to rely on malloc(). So, that leaves a few questions: 1. Would it actually be a problem for an sync-signal-safe implementation of malloc() to be called in this scenario? 2. Is such an implementation even possible? 3. Are you willing to take the chance that anyone would actually ship one AND dare to use it in any of POSIX's mandated async-signal-safe functions? (Also, it has come to my attention that s*printf() are actually functions which are not on the list -- somehow, the nature of their task had gotten them past my radar -- so it's presumably simplest to have the helper script get the parent PID on its own, rather than passing it on the command line as I had initially imagined.)