From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13883 invoked by alias); 8 Jan 2013 21:41:37 -0000 Received: (qmail 13871 invoked by uid 22791); 8 Jan 2013 21:41:36 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jan 2013 21:41:31 +0000 Received: by mail-we0-f177.google.com with SMTP id x48so700640wey.8 for ; Tue, 08 Jan 2013 13:41:30 -0800 (PST) X-Received: by 10.194.238.5 with SMTP id vg5mr103833573wjc.40.1357681290740; Tue, 08 Jan 2013 13:41:30 -0800 (PST) Received: from [192.168.1.26] (88.Red-83-49-114.dynamicIP.rima-tde.net. [83.49.114.88]) by mx.google.com with ESMTPS id u6sm1029699wif.2.2013.01.08.13.41.27 (version=SSLv3 cipher=OTHER); Tue, 08 Jan 2013 13:41:29 -0800 (PST) Message-ID: <50EC9207.20100@gmail.com> Date: Tue, 08 Jan 2013 21:48:00 -0000 From: =?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?= User-Agent: Thunderbird MIME-Version: 1.0 To: =?UTF-8?B?VG9iaWFzIFJpbmdzdHLDtm0=?= CC: gcc-help@gcc.gnu.org Subject: Re: Problem with noexcept and incomplete backtrace References: <50EC4D9E.3070703@ringis.se> In-Reply-To: <50EC4D9E.3070703@ringis.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00061.txt.bz2 On 08/01/13 17:47, Tobias Ringström wrote: > I've discovered a problem with backtraces when using noexcept, but I > don't know if it's a bug, required behaviour, or if I'm missing > something. I'd appreciate a little guidance. > > The problem is that when an exception is thrown and there's a > "noexcept" function earlier in the call stack, the backtrace is > sometimes incomplete, i.e. it ends before the throw location. > Specifically, it seems to end at the first function above the > "noexcept" function that has an object with a destructor in it. > > It's probably easier to understand with an example: (...) > As you can see, bad_guy is not in the backtrace. > > There are two simple modifications that makes the backtrace complete. > The first is to remove the noexcept from level1, and the second is to > remove the Foo declaration in level2 (or delete Foo's destructor). I > really need the noexcept because in my real application, level1 is a > thread main function, which needs the noexcept, or I don't any call > stack below libstdc++'s thread caller, because it has a try/catch all > block to call terminate. > > Should I file a bug report? I've tested 4.6.3, 4.7.2 and > 4.8-20130106, with identical results. > > /Tobias You are lying to the compiler there. OTOH, level1 shall not throw any exception (has noexcept), OTOH it *is* throwing an exception. So I gues you're at undefined behavior. What about surrounding the content of level with a try catch all ?