public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Tobias Ringström" <tobias@ringis.se>
To: gcc-help@gcc.gnu.org
Subject: Problem with noexcept and incomplete backtrace
Date: Tue, 08 Jan 2013 18:00:00 -0000	[thread overview]
Message-ID: <50EC4D9E.3070703@ringis.se> (raw)

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:

     class Foo
     {
     public:
         Foo() { }
         ~Foo() { }
     };
     void bad_guy()
     {
         throw "die die die";
     }
     void level2()
     {
         Foo foo;
         bad_guy();
     }
     void level1() noexcept
     {
         level2();
     }
     int main()
     {
         level1();
     }

# g++ -std=c++0x -g tmp3.cpp
# gdb a.out
[...]
(gdb) bt
#0  0x000000318f036285 in raise () from /lib64/libc.so.6
#1  0x000000318f037b9b in abort () from /lib64/libc.so.6
#2  0x00000031964bbc5d in __gnu_cxx::__verbose_terminate_handler() ()
    from /usr/lib64/libstdc++.so.6
#3  0x00000031964b9e16 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x00000031964b8e49 in ?? () from /usr/lib64/libstdc++.so.6
#5  0x00000031964b973d in __gxx_personality_v0 ()
    from /usr/lib64/libstdc++.so.6
#6  0x000000319000f6fb in ?? () from /lib64/libgcc_s.so.1
#7  0x000000319000fb58 in _Unwind_Resume () from /lib64/libgcc_s.so.1
#8  0x0000000000400722 in level2 () at tmp3.cpp:14
#9  0x000000000040072b in level1 () at tmp3.cpp:18
#10 0x0000000000400736 in main () at tmp3.cpp:22

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

             reply	other threads:[~2013-01-08 16:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08 18:00 Tobias Ringström [this message]
2013-01-08 21:48 ` Ángel González
2013-01-08 21:53   ` Jonathan Wakely
2013-01-08 22:19     ` Jonathan Wakely
2013-01-09 10:30       ` Tobias Ringström
2013-01-09 10:44         ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50EC4D9E.3070703@ringis.se \
    --to=tobias@ringis.se \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).