public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "avi at scylladb dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/105373] New: miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor Date: Mon, 25 Apr 2022 09:31:13 +0000 [thread overview] Message-ID: <bug-105373-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 Bug ID: 105373 Summary: miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor Product: gcc Version: 11.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: avi at scylladb dot com Target Milestone: --- This is a bug in a complex piece of code, so I'll need guidance on what further information to provide (e.g. intermediate code dumps). It reproduces with various levels of debug information, and the code works with clang. At the heart there is a shared pointer, which I've enhanced so that all pointers that point to the same object keep track of each other (also the pointee points back to one of the pointers). The pointee keeps an incrementing generation count. In the end I have two pointer objects that are bitwise equal, even though they should have different generation counts and different doubly-linked-list pointers. This proves that a bitwise copy happened. It doesn't prove a miscompile, since my code could have decided to perform a bitwise copy, but the fact that it works in clang indicates it's a gcc bug. The bug happens with asan too, and with different sizeof(the smart pointer) so it's not some stray write. This is the snippet that causes the trouble: 0 tlogger.info("before updating cache {}", fmt::ptr(old3.get())); 1 co_await with_scheduling_group(_config.memtable_to_cache_scheduling_group, [this, old4 = old3, &newtabs] () -> future<> { 2 tlogger.info("updating cache {}", fmt::ptr(old4.get())); 3 return update_cache(old4, newtabs); 4 }); old3 and old4 are all copies of the same smart pointer (there are also old and old1 and old2 elsewhere, but they are correct). In the call to update_cache(), we attempt to make a copy of old4, and an internal check finds the link list is corrupted. Inspecting old4 in the debugger (from the printout in line 0) and the source of the copy in line 3 shows they are the same, but have different addresses: 0 INFO 2022-04-25 12:04:14,722 [shard 0] table - before updating cache 0x600000666c40 1 copying @0x60000520bef8 <- @0x6000052108f0 0x600000666c40 refcnt 6 gen 43 2 INFO 2022-04-25 12:04:14,722 [shard 0] table - updating cache 0x600000666c40 3 (gdb) p this $1 = (const seastar::lw_shared_ptr<replica::memtable> * const) 0x60000520bed0 4 (gdb) p *this 5 $2 = {_ptr = 0x600000666c40, _next = 0x6000052108f0, _prev = 0x60000597ae48, _generation = 43} 6 (gdb) x/4gx 0x60000520bef8 7 0x60000520bef8: 0x0000600000666c40 0x00006000052108f0 8 0x60000520bf08: 0x000060000597ae48 0x000000000000002b 9 (gdb) x/4gx this 10 0x60000520bed0: 0x0000600000666c40 0x00006000052108f0 11 0x60000520bee0: 0x000060000597ae48 0x000000000000002b in line 3 I dump old4 (from the printout in line 1, where old3 is copied into old4). But "this" doesn't point to old4., it points to a bitwise copy of old4, as shown in lines 7-8 and 10-11. Note that both old4 and the bad copy "this" are members of the coroutine frame. I realize this isn't enough to analyze the situation, I'm happy to provide more information if you direct me how.
next reply other threads:[~2022-04-25 9:31 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-25 9:31 avi at scylladb dot com [this message] 2022-04-25 11:14 ` [Bug c++/105373] " avi at scylladb dot com 2022-04-25 11:47 ` avi at scylladb dot com 2022-04-25 12:21 ` avi at scylladb dot com 2022-04-25 19:37 ` iains at gcc dot gnu.org 2022-04-26 9:38 ` avi at scylladb dot com 2022-04-26 9:43 ` avi at scylladb dot com 2022-04-26 10:07 ` avi at scylladb dot com 2022-04-28 14:29 ` avi at scylladb dot com 2022-04-28 14:52 ` avi at scylladb dot com 2022-04-28 14:59 ` avi at scylladb dot com 2022-04-28 17:28 ` avi at scylladb dot com 2022-04-28 18:59 ` iains at gcc dot gnu.org 2022-04-29 19:54 ` iains at gcc dot gnu.org 2022-05-01 14:47 ` avi at scylladb dot com 2022-05-06 11:25 ` avi at scylladb dot com 2022-11-21 13:01 ` avi at scylladb dot com 2022-12-04 14:28 ` avi at scylladb dot com 2022-12-10 12:00 ` iains at gcc dot gnu.org 2022-12-10 12:02 ` 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-105373-4@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).