From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A4B8438708F0; Thu, 14 May 2020 11:46:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A4B8438708F0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1589456813; bh=SHVAUiE0PQSPmM0i5IRtdDjnKBMVv+Cw6zGkcwep7Y0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CMOsdwXqltB4+gOXAayyHahgvKBota0tze76vkjwzkHNTX9q3N844IiHRtDPfhDD6 4ygTyzQr7KuvDoXaun1oXpvcR0j1CgvDnMfT4b1rYtDW7Mye8B9dr41KhVCDOyy1vv geZV/QKCBkZIk+sQonrArBLUfG4LAhHBh47bv3DM= From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/95111] coroutines use-after-free with lambdas Date: Thu, 14 May 2020 11:46:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.1.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: iains at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 11:46:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95111 --- Comment #14 from Iain Sandoe --- (In reply to Ville Voutilainen from comment #12) > It sure seems to me that a coroutine lambda's captures should be copied to > the coroutine state. I don't think the standard says that anywhere. Maybe I am missing your point (some of these things were decided long befor= e I joined the fray) ---- Well, the standard is pretty much silent on coros + lambdas. However, the implementors (Richard, Gor, me, et al) had a long discussion on the topic before Prague - and took what we could from that to Core. GCC does not comply with the (agreed in that discussion) intent that the capture object should be treated in the same manner as 'this', and a refere= nce passed to the traits lookup, promise parms preview and allocator lookup. I have a patch for this (will post this week) - but the only implementation w= ith this correct so far is MSVC clang passes a ref to the traits but does not pass anything for the closure object pointer to promise param preview or allocator) GCC currently passes the object pointer to all three. =3D=3D=3D=3D The idea of bringing the lambda's captures into the coro frame was what I originally implemented. Richard pointed out that this is wrong when the la= mbda is mutable (see gcc/testsuite/g++.dg/coroutines/torture/lambda-10-mutable.C) so if one has auto X =3D [...] () -> some_coro {}; X must exist for the duration of the lambda coro [it was pointed out by Lew= is that really this is only the same as saying that if you have a class with a member function lambda, the instance of that class has to persist for the duration of the coro]. We are, I believe, collectively agreed that this is a 'foot gun' (and rvalue refs doubly so); however, making a better mousetrap here might require some considerable thought. I'm happy to be educated if there's some different consensus as to what to = do, and to amend the GCC impl. accordingly.=