From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24343 invoked by alias); 23 Jun 2008 19:37:40 -0000 Received: (qmail 24334 invoked by uid 22791); 23 Jun 2008 19:37:40 -0000 X-Spam-Check-By: sourceware.org Received: from dessent.net (HELO dessent.net) (69.60.119.225) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 19:37:22 +0000 Received: from localhost ([127.0.0.1] helo=dessent.net) by dessent.net with esmtp (Exim 4.50) id 1KArqb-0002DY-1F; Mon, 23 Jun 2008 19:37:05 +0000 Message-ID: <485FFBD8.6E368E9C@dessent.net> Date: Mon, 23 Jun 2008 19:37:00 -0000 From: Brian Dessent Reply-To: gdb@sourceware.org X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: Pedro Alves CC: gdb@sourceware.org, Eli Zaretskii , Michael Snyder , divis1969@mail.ru Subject: Re: How to catch GDB crash References: <1214241124.3601.1180.camel@localhost.localdomain> <200806231936.32289.pedro@codesourcery.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-06/txt/msg00224.txt.bz2 Pedro Alves wrote: > for native Windows apps, there is some registry key (I don't > remember which) you can set to point to a JIT debugger. Probably For the sake of the archives it's HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug, see . > a little exe wrapper is needed to translate the incoming args > to GDB args, that's all. The first %ld in the command expands to the faulting PID so "path-to\gdb.exe -p %ld" ought to work without need for a wrapper. > I can't see what changes in GDB > would be required? The main problem is that gdb thinks that it's attaching to a normal running process, rather than a faulted app. Thus the current thread is an artificial one with %eip in ntdll!DbgUiConnectToDbg which is just a convenient 'int3' that lives in ntdll.dll as discussed. That's easily fixed just by switching to the thread of interest, however the state of that thread often looks something bogus like this: (gdb) bt #0 0x7c90eb94 in ntdll!LdrAccessResource () from C:\WINXP\system32\ntdll.dll #1 0x7c90e9ab in ntdll!ZwWaitForMultipleObjects () from C:\WINXP\system32\ntdll.dll #2 0x7c86372c in UnhandledExceptionFilter () from C:\WINXP\system32\kernel32.dll #3 0x00000002 in ?? () #4 0x0022f560 in ?? () #5 0x00000001 in ?? () #6 0x00000001 in ?? () #7 0x00000000 in ?? () The actual location of the fault in the user code is nowhere evident (in this testcase, it was at eip 00401304) because gdb doesn't know that it has picked up in the middle of a fault. You can get things back on track by re-triggering the same fault again by continuing, but this really isn't pretty and doesn't always work. For this to work correctly gdb would need some command line switch to tell it that it's taking over a faulted process as the JIT, rather than breaking in on a normally executing one. Brian