From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 42184 invoked by alias); 28 Aug 2016 07:48:28 -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 42081 invoked by uid 89); 28 Aug 2016 07:48:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=saint, Saint, russia, Probably X-HELO: mircat.net Received: from mircat.net (HELO mircat.net) (81.9.105.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 Aug 2016 07:47:54 +0000 Received: from mircat.net ([81.9.105.50]:54318) by mircat.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1bduop-0003ti-7c; Sun, 28 Aug 2016 10:47:51 +0300 Subject: Re: collecting data from a coring process To: Paul Marquess , vijay nag , "gdb@sourceware.org" References: From: Dmitry Samersoff Message-ID: <87b59611-f5d1-628d-fd41-85ce6c6eb50b@samersoff.net> Date: Sun, 28 Aug 2016 07:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hsiqAMPcs6GWEs5xnUb6HCg7vviK6MdDA" X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00051.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hsiqAMPcs6GWEs5xnUb6HCg7vviK6MdDA Content-Type: multipart/mixed; boundary="P1Rcw7ljL2x5njMjuWx7qbp6SitUxXrKn" From: Dmitry Samersoff To: Paul Marquess , vijay nag , "gdb@sourceware.org" Message-ID: <87b59611-f5d1-628d-fd41-85ce6c6eb50b@samersoff.net> Subject: Re: collecting data from a coring process References: In-Reply-To: --P1Rcw7ljL2x5njMjuWx7qbp6SitUxXrKn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 3670 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. If you use altstack and avoid malloc you can dump bunch of information from the signal handler more or less safely. e.g. http://hg.openjdk.java.net/jdk9/hs/hotspot/file/tip/src/share/vm/utilities/= vmError.cpp >>> 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 One of possible solution is: 1. Change /proc/sys/kernel/core_pattern to have all coredumps from your app in a separate directory, something like /var/dumps/%e/core.%p 2. Have a cron job that looks over this directory and run gdb < gdb_script > core.%p.out on demand. -Dmitry On 2016-08-26 15:33, Paul Marquess wrote: > From: vijay nag [mailto:vijunag@gmail.com] >> Sent: 26 August 2016 13:02 To: Paul Marquess >> Cc: gdb@sourceware.org Subject: Re: >> collecting data from a coring process >>=20 >> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> Unable to attach: program terminated with signal SIGSEGV, >>> Segmentation fault. No stack. >>>=20 >>> 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. >>>=20 >>> Anyone know of a way to do this? Preferably one that doesn't >>> involve changing the process itself. >>>=20 >>> cheers Paul >> You can do one of the following >>=20 >> 1) Why not dump the information that you are looking for into a >> file in the process signal handler ? >=20 > 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. >=20 > For now, using gdb means I'm isolated from the risk of the data > collection crashing the process again inside the signal handler. >=20 >> 2) RTFM core file piping on linux (Probably you've done this >> already >=20 > Looked, but did not find anything. >=20 >> ?) - The idea may seem dangerous, but you can try inserting sleep >> in the script for sometime till you gather whatever information >> that is required. >=20 > Not sure what you mean by this. Can you elaborate please? >=20 > Paul >=20 --=20 Dmitry Samersoff Saint Petersburg, Russia, http://devnull.samersoff.net * There will come soft rains ... --P1Rcw7ljL2x5njMjuWx7qbp6SitUxXrKn-- --hsiqAMPcs6GWEs5xnUb6HCg7vviK6MdDA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 473 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXwpb8AAoJEHEy08c4gIAB6z4H/1DOVYSHPrd5/Ek2xdOUeK8e Gww75eNSi90jvARsXlHzyGUoujmqZCzRDzRAeY/swRNrF+GYlr0ZRjKS8VRfEnf8 6acnODkJ4c1ArwOFBM/LohH/p3Sjmh40vtITX6sIunZT8d4wk27lX6xvpZjO2reo ZocyoVO7CEmTduqHc/exQ49OL40fy/2HHKqPlkr0bnsvXMclbjtl9Z6A1NSfxkRR snR8La1YKxCu90H6HLQQa/F+ljf5DgOjSXqDOUU8vYD6s5aTuNhUK3iaHpvYYbez wD6CHDZnre/U+BcTWJj8CKtoeNp4PrVF2fCoVG9SlrUIeEAJmIvwCD2oSYmM3zA= =gU1d -----END PGP SIGNATURE----- --hsiqAMPcs6GWEs5xnUb6HCg7vviK6MdDA--