From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-049.btinternet.com (mailomta26-sa.btinternet.com [213.120.69.32]) by sourceware.org (Postfix) with ESMTPS id 5AC363857C53 for ; Mon, 24 Aug 2020 17:02:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5AC363857C53 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-049.btinternet.com with ESMTP id <20200824170214.HAQJ4195.sa-prd-fep-049.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net>; Mon, 24 Aug 2020 18:02:14 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [31.51.206.39] X-OWM-Source-IP: 31.51.206.39 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduiedruddukedgheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepgeeuhfekvdefieeghfehtdejheeigedthefhhfehfffgheehgedtffeljeetueeunecukfhppeefuddrhedurddvtdeirdefleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepfedurdehuddrvddtiedrfeelpdhmrghilhhfrhhomhepoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeoghgusgdqphgrthgthhgvshesshhouhhrtggvfigrrhgvrdhorhhgqedprhgtphhtthhopeeoshhimhgrrhhksehsihhmrghrkhdrtggrqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (31.51.206.39) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9AA6E0D3C60A3; Mon, 24 Aug 2020 18:02:14 +0100 Subject: Re: [PATCH 1/4] Add sniffer for Cygwin x86_64 core dumps To: gdb-patches@sourceware.org References: <20200812191816.23246-1-jon.turney@dronecode.org.uk> <20200812191816.23246-2-jon.turney@dronecode.org.uk> <9c6ae1b6-c8b2-6219-1e2a-ed4954350fb1@dronecode.org.uk> <78accded-bb48-8d01-4feb-9d90002d5935@dronecode.org.uk> <83585eda-b7ec-5735-d03e-d07ed7bcb3fe@simark.ca> <21fa41cf-ca6c-061e-2036-07c283313a41@simark.ca> From: Jon Turney Cc: Simon Marchi Message-ID: <5def8e4e-c777-1844-3786-5d4d2e0cae1a@dronecode.org.uk> Date: Mon, 24 Aug 2020 18:02:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <21fa41cf-ca6c-061e-2036-07c283313a41@simark.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 17:02:18 -0000 On 24/08/2020 16:47, Simon Marchi wrote: > On 2020-08-22 3:52 p.m., Jon Turney wrote: >> >> Hmmm. This often means the executable can't be started due to problems >> loading DLLs. >> >> If you want to pursue this further, running under cygwin's strace (e.g. >> 'strace dumper') might shed more light. > > Ahh, I downloaded the x86 version of the snapshot instead of the x86-64! :) > When using dumper.exe from the x86-64, it works. I that dumper.exe from the > snapshot also runs much faster than the original dumper.exe, don't know if that's > expected. Yeah, I fixed some bogosity which was making it slow. > I now get this: > > $ ./gdb -q --data-directory=data-directory ~/a.exe -ex "core ~/core.core" > Reading symbols from /home/simark/a.exe... > warning: core file may not match specified executable file. > [New process 6408] > [New process 6504] > [New process 904] > [New process 5068] > [New process 4892] > #0 0x00007ff92bba01b4 in ?? () > [Current thread is 1 (process 6408)] > (gdb) bt > #0 0x00007ff92bba01b4 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > Since I just copied my binary and core out of Cygwin, and the program was stopped somewhere > under sleep(), it's perhaps expected that GDB has trouble unwinding from system libraries > it doesn't have access to. Yeah, I don't think unwinding is going to be very successful in that case. Thanks for trying it out. The "testing" I have been doing is mainly: > $ cat dumper-test.c > > void fault() > { > // deref null pointer > *(int *)0 = 1; > } > > int main() > { > fault(); > } > > $ gcc -g -O0 dumper-test.c -o dumper-test.exe > > $ CYGWIN='error_start=dumper' ./dumper-test > > $ gdb dumper-test.exe dumper-test.exe.core > [...] > (gdb) bt > #0 0x00007ffb4498fc20 in ntdll!KiUserExceptionDispatcher () from C:/WINDOWS/SYSTEM32/ntdll.dll > #1 0x0000000100401089 in fault () at dumper-test.c:5 > #2 0x00000001004010a4 in main () at dumper-test.c:10