From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-451720-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9518 invoked by alias); 15 May 2014 22:55:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 9465 invoked by uid 48); 15 May 2014 22:55:40 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60966] std::call_once sometime hangs
Date: Thu, 15 May 2014 22:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60966-4-l5RgoQzHSi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60966-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60966-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01412.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

--- Comment #19 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #16)
> The easiest fix is to call get_future() before passing the task into a new
> thread, and store it in a std::vector<std::future<void>>

Actually this only hides the error (by ensuring the shared state is not deleted
because there is a future object still referring to it) but the fundamental
problem with that code remains:

You are calling the promise destructor before the call to set_value()
completes.

You are assuming that as soon as the shared state becomes ready the promise is
no longer in use, but that's not true. After the shared state is made ready the
rest of the set_value() function runs, which accesses members of the shared
state. If you destroy the promise (and it has the only reference to the shared
state) then it will destroy its members while they are still being used.

This is a bug in your code, std::promise is like any other type: you must not
delete it while another thread is still using it.