http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185
Bug #: 54185
Summary: condition_variable not properly destructed
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: architect...@hotmail.com
Created attachment 27947
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27947
a possible patch to solve the problem
The c11 standard (draft 3337, paragraph 30.5.1.5) states that
condition_variable may be destructed even if not all wait() calls have
returned, so long as all of those calls are blocking on the associated lock
rather than on *this. However, in gcc 4.7.1 the following snippets sometimes
fail with a segfault in thread A or simply inconsistent results:
condition_variable *volatile cond = new condition_variable;
// in thread A
cond->wait();
// in thread B, later
cond->notify_all();
delete cond;
It appears that the underlying libpthread also allows the destruction of cond
immediately after all blocking threads have been notified, by means of a block
in __pthread_cond_destroy while all of the wait() calls wake and begin to
reacquire their locks.
However, the current implementation in condition_variable.cc uses a default
destructor:
condition_variable::~condition_variable() noexcept = default;
rather than calling __gthread_cond_destroy, and therefore the pthread cond
object is deleted without the block provided by __pthread_cond_destroy.
The attached patch seems to fix the problem with gcc-4.7.1 (verified on my
system, x86_64-pc-linux-gnu).
The patch undoes the replacement (in the presence of __GTHREAD_COND_INIT) of
~condition_variable with "= default" from
http://gcc.gnu.org/viewcvs?view=revision&revision=180411, which seems to have
been inadvertent.
