From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101237 invoked by alias); 4 Oct 2018 09:18:09 -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 101221 invoked by uid 89); 4 Oct 2018 09:18:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*UA:Firefox, toward, Turney, turney X-HELO: m0.truegem.net Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 04 Oct 2018 09:18:07 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id w949I526052934 for ; Thu, 4 Oct 2018 02:18:05 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 76-217-5-154.lightspeed.irvnca.sbcglobal.net(76.217.5.154), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdMZuc0q; Thu Oct 4 02:18:02 2018 Subject: Re: An increment to Jon Turney's stackdump2backtrace script To: cygwin@cygwin.com References: <8541aec5-b9f1-c9c4-bdc6-2f5940d10bc2@dronecode.org.uk> From: Mark Geisert Message-ID: <8ff3264e-eb21-25f7-6a45-76b7309738f7@maxrnd.com> Date: Thu, 04 Oct 2018 09:18:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <8541aec5-b9f1-c9c4-bdc6-2f5940d10bc2@dronecode.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-10/txt/msg00037.txt.bz2 Jon Turney wrote: > 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. True. It's geared toward my workflow which only deals with stuff I've built on my own machine and debugging/fixing pretty soon after causing the stackdump. Any update to any of the files involved risks invalidating the stackdump. > (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... Huh. I'll see if I can find them in the cygwin-patches archive. > It would perhaps be better to write a minidump, which captures that information > (and more...) Are you alluding specifically to Windows minidump or just generally a small information dump? On a related topic, I noticed dumper.exe in winsup/utils and played around with it. I'm unsure if it captures everything one would want in a corefile. I'm also unsure if there could even be a PE/COFF corefile and what it would contain. Cheers, ..mark -- 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