public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug go/60406] recover.go: test13reflect2 test failure Date: Tue, 07 Oct 2014 09:12:00 -0000 [thread overview] Message-ID: <bug-60406-4-ljH882GiRp@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #17 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- >> * Wouldn't the new patch re-introduce the bug that >> >> func foo(n int) { >> if (n == 0) { recover(); } else { foo(0); } >> } >> func main() { >> defer foo(1) >> panic("...") >> } >> >> would recover although it should not? > > Hmmm, I hadn't fully internalized that issue. Your new > withoutRecoverRecursive test doesn't fail for me on x86_64. I think you have implicitly fixed this issue by splitting functions that call recover() into two parts (i.e. main.foo and main.foo$recover). So recursive calls originate from the ...$recover function and never match the return address check. Well, maybe it was only a problem with tail recursion, i.e. func foo(n int) int { if (n == 0) { recover(); return 0; } return foo(0) } Would be optimized to a loop, removing the function call, and then the return address check would trigger. That's not possible with two function approach. But if there's another criterion to allow recover that simply depends on the caller's name the problem might reappear. >> * The code is even more expensive than the approach I had chosen because >> now it needs to fetch a two level backtrace instead of just one level >> (and probably each level is more expensive than the one >> _Unwind_FindEnclosingFunc()). > > Yes, but the expensive case only happens in the rare cases where > either recover should not work or when the existing code has a > false negative. Hm, so the patch penalises platforms that cannot deal with the 16 byte window? >> func main() { defer foo(); panic("..."); } >> func foo() { defer bar(); } >> func bar() { recover(); } > > In this case, the call to recover in bar is supposed to return nil; > it should not recover the panic. If you read the paragraph before > the one you quote, you will see that recover only returns non-nil > if it was called by a function that was deferred before the call to > panic. I've read it but cannot see anything that would disallow recovery in this situation. What exactly do you mean? >> 4) __go_can_recover assumes that any call through libffi is allowed >> to recover. > > Thanks for the example. Does your patch fix this problem? No, I just became aware of the problem when reviewing the code last week.
next prev parent reply other threads:[~2014-10-07 9:12 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-03-04 7:30 [Bug go/60406] New: reflect.go:test13reflect2 " vogt at linux dot vnet.ibm.com 2014-08-06 17:04 ` [Bug go/60406] recover.go: test13reflect2 " ubizjak at gmail dot com 2014-08-07 8:47 ` ubizjak at gmail dot com 2014-08-07 10:34 ` ubizjak at gmail dot com 2014-09-04 15:52 ` ian at airs dot com 2014-09-05 7:15 ` vogt at linux dot vnet.ibm.com 2014-09-16 20:57 ` boger at us dot ibm.com 2014-09-22 20:57 ` boger at us dot ibm.com 2014-09-23 13:34 ` bergner at gcc dot gnu.org 2014-09-29 13:17 ` boger at us dot ibm.com 2014-10-03 22:59 ` ian at airs dot com 2014-10-06 15:43 ` vogt at linux dot vnet.ibm.com 2014-10-06 15:48 ` boger at us dot ibm.com 2014-10-07 9:12 ` vogt at linux dot vnet.ibm.com [this message] 2014-10-07 13:56 ` ian at airs dot com 2014-10-07 18:25 ` ian at airs dot com 2014-10-08 5:49 ` ubizjak at gmail dot com 2014-10-08 8:12 ` vogt at linux dot vnet.ibm.com 2014-10-08 10:13 ` vogt at linux dot vnet.ibm.com 2014-10-08 13:28 ` ian at airs dot com 2014-10-08 13:44 ` ian at airs dot com 2014-10-08 14:15 ` ian at airs dot com 2014-10-28 8:55 ` vogt at linux dot vnet.ibm.com
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=bug-60406-4-ljH882GiRp@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).