public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pigman46 at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address Date: Sat, 06 Nov 2021 05:07:56 +0000 [thread overview] Message-ID: <bug-98401-4-nhiWazscmZ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98401-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 Michael Theall <pigman46 at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pigman46 at gmail dot com --- Comment #5 from Michael Theall <pigman46 at gmail dot com> --- This is also happening for me. In my case i have a promise_type defined by coroutine_traits. This promise_type contains only a shared_ptr, which is constructed via make_shared on default and move constructors, and the copy constructor is deleted. a promise_type x is default-constructed and then immediately another promise_type y is move-constructed from x but with the wrong reference. I'll call it x'. promise_type contains a shared_ptr which has the same reference in both x and x' although x' is never constructed, and the shared_ptr has a refcount of 1. So now we have x with its original shared_ptr 'a'. We have x' with some unspecified shared_ptr 'b' (it was swapped or destroyed when moved to y). We have y also with shared_ptr 'a'. The refcount of 'a' at this point is still 1. Then, by the time my coroutine returns, all of x, x', and y are destructed, which means shared_ptr 'a' is destructed too many times. shared_ptr 'b' is fine. If I assign the awaitable to a local variable and then co_await that instead, the problem does not occur. In no cases does the problem occur with clang. Same behavior on GCC 11.2.1 x86_64 with -std=c++20 and GCC 11.1.0 aarch64 with -std=gnu++20. The problem occurs regardless of optimization level and whether LTO is enabled, if that makes any difference.
next prev parent reply other threads:[~2021-11-06 5:07 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-20 16:39 [Bug c++/98401] New: " brandt.milo2 at gmail dot com 2020-12-20 16:40 ` [Bug c++/98401] " brandt.milo2 at gmail dot com 2021-01-09 19:56 ` dpsicilia at gmail dot com 2021-06-10 14:28 ` davidledger at live dot com.au 2021-06-23 8:55 ` victor.burckel at gmail dot com 2021-11-06 5:07 ` pigman46 at gmail dot com [this message] 2021-12-28 4:02 ` [Bug c++/98401] coroutines: " brandt.milo2 at gmail dot com 2021-12-28 4:03 ` brandt.milo2 at gmail dot com 2021-12-28 4:04 ` brandt.milo2 at gmail dot com 2021-12-28 10:03 ` iains at gcc dot gnu.org
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-98401-4-nhiWazscmZ@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).