From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-42450-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 28171 invoked by alias); 9 Aug 2013 13:58:03 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 28145 invoked by uid 89); 9 Aug 2013 13:58:03 -0000
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.1
Received: from Unknown (HELO mtaout22.012.net.il) (80.179.55.172)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 09 Aug 2013 13:58:02 +0000
Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MR900C00NXJLV00@a-mtaout22.012.net.il> for gdb@sourceware.org; Fri, 09 Aug 2013 16:57:45 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MR900CIEO49JL40@a-mtaout22.012.net.il>; Fri, 09 Aug 2013 16:57:45 +0300 (IDT)
Date: Fri, 09 Aug 2013 13:58:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: How to debug fatal exceptions on Windows?
In-reply-to: <"000001ce92bb$ff059a60$fd10cf20$@muller"@ics-cnrs.unistra.fr>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: gdb@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83fvujrmol.fsf@gnu.org>
References: <83y58evno4.fsf@gnu.org> <"000001ce92bb$ff059a60$fd10cf20$@muller"@ics-cnrs.unistra.fr>
X-SW-Source: 2013-08/txt/msg00047.txt.bz2

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Aug 2013 17:45:36 +0200
> 
>   I could be that some "special" exception code is 
> used that is not understood by GDB.
>   In fact, an exception is send first to the debugger,
> then to the debuggee, and lastly again to the debugger if not handled by the
> debuggee.
> 
>   But if GDB does not recognize the exception code,
> it dies nothing on the first pass. 
> And the code is then caught by the gnu_exception_handler.

That is true, but it is unrelated to the issue I was having.  In the
use case I described, GDB was attached to Emacs when Windows already
displayed the "application needs to close" dialog.  At that point, the
search for exception handler already found the _gnu_exception_handler
function installed by the MinGW startup code, and called it.  The
problem is that the call stack down to the place that caused the
exception is not visible to GDB at this point.

So I think the possibility of GDB seeing an unknown exception on the
first chance call is not the problem here.