From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64660 invoked by alias); 3 Oct 2018 17:08:23 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 64648 invoked by uid 89); 3 Oct 2018 17:08:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=relocated, captures, Hx-languages-length:1039, his X-HELO: rgout0707.bt.lon5.cpcloud.co.uk Received: from rgout0707.bt.lon5.cpcloud.co.uk (HELO rgout0707.bt.lon5.cpcloud.co.uk) (65.20.0.147) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Oct 2018 17:08:22 +0000 X-OWM-Source-IP: 31.51.205.159 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-SNCR-VADESECURE: CLEAN Received: from [192.168.1.102] (31.51.205.159) by rgout07.bt.lon5.cpcloud.co.uk (9.0.019.26-1) (authenticated as jonturney@btinternet.com) id 5B9AED2F01BBCFA2 for cygwin@cygwin.com; Wed, 3 Oct 2018 18:08:20 +0100 Subject: Re: An increment to Jon Turney's stackdump2backtrace script To: The Cygwin Mailing List References: From: Jon Turney Message-ID: <8541aec5-b9f1-c9c4-bdc6-2f5940d10bc2@dronecode.org.uk> Date: Wed, 03 Oct 2018 17:08:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00027.txt.bz2 On 01/10/2018 10:20, Mark Geisert wrote: > For those Cygwin developers who tend to attract stackdump files... > > ..mark (who defines an alias 'bt' to launch the script because he can't > get gdb out of his head) Nice. Thanks. > OTHERS=`ldd $IMG1 | awk '{print $3}' | sort -r | tr '\\n' ' '` One thing you should be aware of here is that you are assuming that the other DLLs (i) have the same base address locally and on the system where the stackdump was generated [an assumption which rebase will tend to invalidate], and (ii) don't get relocated. (The executable and cygwin1.dll don't suffer from this problem, as they have fixed addresses in the process memory layout used by cygwin) For this reason, stackdumps are a weak tool for debugging crashes in other DLLs. There were some patches posted to add DLL load addresses to the stackdump, not sure what happened to them... It would perhaps be better to write a minidump, which captures that information (and more...) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple