From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19279 invoked by alias); 7 Oct 2014 17:25:54 -0000 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 Received: (qmail 19265 invoked by uid 89); 7 Oct 2014 17:25:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Oct 2014 17:25:51 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ND300B00461MA00@a-mtaout20.012.net.il> for gdb@sourceware.org; Tue, 07 Oct 2014 20:25:48 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND300B344F0IJ40@a-mtaout20.012.net.il>; Tue, 07 Oct 2014 20:25:48 +0300 (IDT) Date: Tue, 07 Oct 2014 17:25:00 -0000 From: Eli Zaretskii Subject: Re: Reporting the STATUS_INVALID_UNWIND_TARGET fatal error In-reply-to: <54341C7B.70700@redhat.com> To: Pedro Alves Cc: gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83iojvlrkn.fsf@gnu.org> References: <831tqtkn9e.fsf@gnu.org> <54341C7B.70700@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00018.txt.bz2 > Date: Tue, 07 Oct 2014 18:01:47 +0100 > From: Pedro Alves > > On 09/30/2014 06:54 PM, Eli Zaretskii wrote: > > In the native MinGW build of GDB, we currently do not interpret > > STATUS_INVALID_UNWIND_TARGET, neither as a Posix-style signal nor as a > > Windows exception (under debugexceptions). As result, GDB says > > something like > > > > gdb: unknown target exception 0xc0000029 at 0x7c9502cc > > > > Would it make sense to report this as SIGSEGV instead? > > Doesn't sound like segmentation fault, but rather the > runtime detecting some corruption. But stack-related trouble, like stack overflows, are reported as segfaults, right? > Like, e.g., glibc's malloc/free detecting a heap corruption and > printing about that. It's not a case of corruption. Nothing is wrong with the stack per se. In addition, it's a true exception, not a debugging feature provided by some library. So I think it's different. > > This happens, e.g., when a thread tries to longjmp using stack > > information recorded by a different thread. What will GDB report in > > such a case on GNU/Linux or other Posix platforms? > > I think nothing. Could you or someone else try? > In absence of a more specific signal, I think SIGTRAP is the > best match, for being a "debugger" signal. This has the advantage > that SIGTRAP is not passed to the program by default, so a plain > "continue" should suppress the exception, while "signal SIGTRAP" > will pass it to the program (which I guess will usually terminate > the application). You cannot continue from this exception, not on Windows anyway. Your program dies. > Though overall, I think it'd be better if we added a new > "target exception" waitkind or some such, and stopped trying > to masquerade Windows exceptions as Unix signals. What would it take to do something like that?