From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48190 invoked by alias); 13 Jul 2017 09:55:22 -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 46207 invoked by uid 89); 13 Jul 2017 09:55:21 -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,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=client's, H*r:4.85, Ossman, Decoding 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; Thu, 13 Jul 2017 09:55:20 +0000 Received: from [84.47.189.162] (port=48402 helo=[172.27.105.33]) by mircat.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1dVaq4-0009aI-7G; Thu, 13 Jul 2017 12:55:16 +0300 Subject: Re: Decoding stack in core file without correct libs? To: Pierre Ossman , gdb@sourceware.org References: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> From: Dmitry Samersoff Message-ID: <11c23f4e-f3f7-c74d-6c89-8851d2c62bbe@samersoff.net> Date: Thu, 13 Jul 2017 09:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OvWhHLx5DILjX4sX4gl9BeLrkaf0VKS1k" X-Authenticated-As: dms X-SpamProbe: GOOD 0.0000019 3ff614d1e51831cb56901e55c003d033 X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00025.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OvWhHLx5DILjX4sX4gl9BeLrkaf0VKS1k Content-Type: multipart/mixed; boundary="p1C4GqKeIthIejwLvQqnHcqRNLVqnsHPA"; protected-headers="v1" From: Dmitry Samersoff To: Pierre Ossman , gdb@sourceware.org Message-ID: <11c23f4e-f3f7-c74d-6c89-8851d2c62bbe@samersoff.net> Subject: Re: Decoding stack in core file without correct libs? References: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> In-Reply-To: <197a6eed-6163-67ed-67b7-57c4298d851b@cendio.se> --p1C4GqKeIthIejwLvQqnHcqRNLVqnsHPA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 1306 Pierre, You can run command (below) on your own machine: gdb -batch --eval "info shared" binary core 2> /dev/null |\ sed -n -e 's/^.*Yes[^\/]*\//\//p' -e 's/^.*No[^\/]*\//\//p' > filelist and then do cat filelist | zip zipme.zip -@ on client's one. PS: this small article might be helpful. http://www.samersoff.net/do/index.php/blog/19-articles/56-how-to-open-java-= coredump-in-gdb -Dmitry On 07/13/2017 12:24 PM, Pierre Ossman wrote: > Hi, >=20 > I'd like to see if there is a way to produce binaries so that gdb can > walk the stack in a core dump even if the libraries gdb sees doesn't > match the libraries when the core dump was generated. >=20 > My scenario is simply that we might get crashes at customer sites. > Rather than getting some kind of remote access up an running, it would > be easier to have them send us a core dump from the crash. We then load > the core file together with a binary with debug symbols on our end. >=20 > Unfortunately gdb doesn't traverse the stack correctly if the crash is > in a system library. We just get random addresses for each frame. >=20 > It's okay that we cannot get the proper symbols or local variables for > frames that are in system libraries, but is there some way to get access > to the frames that are in our binary? >=20 > Regards --p1C4GqKeIthIejwLvQqnHcqRNLVqnsHPA-- --OvWhHLx5DILjX4sX4gl9BeLrkaf0VKS1k 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 iQEcBAEBCAAGBQJZZ0OEAAoJEHEy08c4gIAByRIIAJZl8YfUyBl7bYr7zcMu/Wtb /xHJPkoW1A6JcCz+FKeYDJXx3QbJrX202L8H/Ix+Z3EAGdjFLaJl5AHeLlgNdZPV qF70PWZvHBGk398N589W87Tknl0TZJNwSk0OM3iRyxYs+YH3iND5FUW6pOfVR4NU W7q1BUyd/L5YYZWJNeib8ynC7lyNG7qL1HT0R5/BwcguVGSPLV56PTBT5QJTYrhg L2+XgPCob+idCrHDNAAwrR40bACrzzYLbzl2I7nJIfvCrnMkzP7nPEimu29rgQQd L17GD3bL/N16LRXha83xN4jD3Rgv7If23t3Qru4nrhVELS9PF/IBGEIWDOnuirY= =kOba -----END PGP SIGNATURE----- --OvWhHLx5DILjX4sX4gl9BeLrkaf0VKS1k--