From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6620 invoked by alias); 1 Sep 2016 04:23:14 -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 6610 invoked by uid 89); 1 Sep 2016 04:23:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=begun, H*F:D*mail.com, sincerely, love X-HELO: mout.gmx.com Received: from mout.gmx.com (HELO mout.gmx.com) (74.208.4.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Sep 2016 04:23:02 +0000 Received: from ulgy_thing ([70.193.211.81]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0MRG93-1bWoQA0GPX-00UX4O; Thu, 01 Sep 2016 06:22:57 +0200 Date: Thu, 01 Sep 2016 04:23:00 -0000 From: David Niklas To: gdb@sourceware.org Cc: Paul Marquess Subject: Re: collecting data from a coring process Message-ID: <20160831151611.1411e3f7@ulgy_thing> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:vAg81/txCvs=:bACU0TraPWi4nxb8ofZ5/I O1dJmRWDY2zD1Xy7NKqK06SkpUWoMzswUIxIOmHBJcggZ6q5Ru5mwSgpHOyTmdyE3b6OkTpDX ZoPcxMRgJl3sfBzfL/TtPEHbyD5MwtUFxvqD2HiiizH2mll8Ib9zN9YV0js/owqnKI5huc1BK eryuIpbMh/SBPBlNaOzI2vC6YGsK9AYXgktDXRvWt+iS/EJ6HwLRXqZ1j2Wnkf993mUdsAvre KzhwLkfgaZ9mBM2TEot88dgZGmDq6khX7i4aUprPNuJKIAFF9kUtQFO0IymaW6OmmrBVU4CIN jolbS5+T6Pt6G9z/g4w1LNbEq8jPOkvvARJb8a6Bcd821bbYa04AmkN5MvlkW/1IafoXRcm/R buePuFaCbdmQEfTl2tvVLRtzcZlinUeLAbLj+dTYZxtrK/LIzsbH0dM0vu2YSHWFVo3d+xXC6 Hq4GPHWdmmO8lXaGpo3/R9IerkQpXceXYm5UAbvQCnZaq4y3Z3f8jajvKzZzjsB+KDdzfe2nN AbXJvZCtZ7dteL6fo0WfIrLnODbDYS2oLPXCl1RnTitSp0CX2mfLU5/9d6YrdAuJ4f563TPK1 +LaeT+bmfjH6pBQmIyCzWAAOVmcXfjZa2UU3PwxXlh2+RCBztgN9fUnuUkDv0gBd9zeOJgE7+ Yxz7/ispcQKgKLtas6o4+hz+aCF/SAG/6ojId/KNVShKBM0zPxAC+lU0EPxoy2SXW/Dfb0MOS h5a5ru7JabH1RoaVlQOS24y0RRAPFF5ANdUybUcM3dvgtuavXaGeT8kkg75AxQirolQsfsPCm nY3odZI X-SW-Source: 2016-09/txt/msg00000.txt.bz2 On Fri, 26 Aug 2016 12:33:24 wrote: > > On Fri, Aug 26, 2016 at 2:36 PM, Paul Marquess > > wrote: > > > I have an existing Linux application that uses gdb to collect data > > > from a process if it cores. Currently I've been doing that with gdb > > > after the core is written to disk. No problem there. > > > > > > The requirements have now changed and it won't be possible to allow > > > the core file to be written to disk. That means I need a way to > > > (somehow) get gdb to collect the data while the process is still in > > > memory. > > > > > > My first thought was to add a script > > > in /proc/sys/kernel/core_pattern to catch the process as it is > > > coring. Then I get gdb to attach to the PID of the process that is > > > about to core. Unfortunately, when I tried that, gdb gives me this > > > error > > > > > > Unable to attach: program terminated with signal SIGSEGV, > > > Segmentation fault. No stack. > > > > > > That seems to imply that by the time /proc/sys/kernel/core_pattern > > > kicks in it is too late to use the PID with gdb. > > > > > > Anyone know of a way to do this? Preferably one that doesn't > > > involve changing the process itself. > > > > > > cheers > > > Paul > > You can do one of the following > > > > 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. Just taking pointes as an example, once in the > signal handler I'm in a situation where I can't trust that any pointer > contains a valid value. A quick search suggests I can guard against > that by using a signal handler. But I'm already in one! If there is > some prior art that shows how to safely dump data from a process once a > SEGV has been triggered it would make my day. > Oh, oh, I know how to do this (finally a chance to be of use on gdb's mailing list :) Ok, assuming that you know what variables you can access or that you can stick them in a struct what you do is enter the signal handler (hear after known as SH), printing the values one by one. When one of the values causes a SEGV then you reenter SH which checks an atomic type to see if your in SH and if so then another atomic type to see if you've begun to print the values. If so then a new branch is executed and what gets printed is an inaccessible error value. Control returns to the first SH and it continues iterating. WARNING: There may be better ways to do what you want, like dump core to a tmpfs (which is in memory anyway so it leaves no trace on disk). Sincerely, David