[Bug libstdc++/54185] New: condition_variable not properly destructed

architectbum at hotmail dot com gcc-bugzilla@gcc.gnu.org
Mon Aug 6 04:19:00 GMT 2012


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: unassigned@gcc.gnu.org
        ReportedBy: architectbum@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.



More information about the Gcc-bugs mailing list