Your message dated Tue, 20 Sep 2016 22:15:11 +0000
with message-id <>
and subject line Bug#838316: Removed package(s) from unstable
has caused the Debian Bug report #810868,
regarding threads: condition_variable or atomic causes _sometimes_ a deadlock
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact

Debian Bug Tracking System
Contact with problems
--- Begin Message ---
Package: g++-4.9
Version: 4.9.2-10
Severity: normal

Dear Maintainer,

there is a mysterious bug in g++ or its libraries.
The bug happens when one compiles and executes the following test code multiple
sometimes the executable just hangs, ie. a deadlock happens.
I think the error lies not in the test code, but in the g++ libraries or even
in g++ itself.


Author: U.Mutlu

condition variable example (but is [sometimes] buggy)

Code adapted from the example at [1]

  How to fix this code?
  --> it could be a low-level issue, ie. compiler-, stdlibrary-, or pthread-

  10 threads race for a job. The main thread supplies the job.
  One of the threads takes the job and processes it.
  This is repeated 10000 times.
  BUT: sometimes the pgm freezes (ie. a deadlock bug happens) --> see below

  g++ -Wall -O2 -std=gnu++11 test.cpp -lpthread

  repeat multiple times (up to 10 times should be ok for the runtime bug to
show up)

Symptoms of the bug:
  sometimes pgm lands in an endless-loop! ie. deadlock happens --> pgm not

Test environment:
  - g++ --version
    g++ (Debian 4.9.2-10) 4.9.2

  - uname -a
    Linux my 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-3~bpo8+2 (2015-12-14)
x86_64 GNU/Linux

  - dpkg -l | grep -i pthread
    ii libpthread-stubs0-dev:amd64  0.3-4  amd64 pthread stubs not provided by
native libc, development files

See also:

#include <iostream>
#include <atomic>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <unistd.h>
#include <vector>

using namespace std;

mutex        mtx;
condition_variable cv;
atomic<bool> fReady;      // init done in main
atomic<bool> fQuit;       // init done in main
atomic<bool> fThreadsOk;  // init done in main

void threadfunc(int id)
Any thread that intends to wait on condition_variable has to acquire a
unique_lock<mutex> first.
The wait operations atomically release the mutex and suspend the execution of
the thread.
When the condition variable is notified, the thread is awakened, and the mutex
is reacquired [2].

    while (!fQuit)
        // wait for fReady:
        unique_lock<mutex> lck(mtx);
        fThreadsOk = true;
        cv.wait(lck);   // unlocks lck, and waits for cv be signalled; then
autom. reacquires lck
        if (fQuit) break;
        if (!fReady) continue;

        // work, ie. process the job:
        cout << "thread " << id << " has grabbed the job\n";

        // notify parent with fReady=false; wakes up also all the other threads
        fReady = false;

int main()
    fQuit      = false;
    fReady     = false;
    fThreadsOk = false;

    const size_t N = 10;
    vector<thread> threads;
    for (size_t i = 0; i < N; ++i)
      threads.push_back(thread(threadfunc, i));

    // wait so that at least one thread has done "cv.wait(lck)", see above
    while (!fThreadsOk) sleep(1);

    for (size_t i = 0; i < 10000; ++i)
        cout << N << " threads ready to race: ";

        // notify threads about work to do
        unique_lock<mutex> lck(mtx);
        fReady = true;

        // wait till job was done
        while (fReady) cv.wait(lck);

    // set fQuit and wake up the threads
    unique_lock<mutex> lck(mtx);
    fQuit = true;

    // wait till all threads quit:
    for (auto& th : threads) th.join();

    cout << "pgm finished\n";
    return 0;

// end of test.cpp

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages g++-4.9 depends on:
ii  gcc-4.9            4.9.2-10
ii  gcc-4.9-base       4.9.2-10
ii  libc6              2.19-18+deb8u1
ii  libcloog-isl4      0.18.2-1+b2
ii  libgmp10           2:6.0.0+dfsg-6
ii  libisl10           0.12.2-2
ii  libmpc3            1.0.2-1
ii  libmpfr4           3.1.2-2
ii  libstdc++-4.9-dev  4.9.2-10
ii  zlib1g             1:1.2.8.dfsg-2+b1

g++-4.9 recommends no packages.

Versions of packages g++-4.9 suggests:
pn  g++-4.9-multilib    <none>
pn  gcc-4.9-doc         <none>
pn  libstdc++6-4.9-dbg  <none>

-- no debconf information

--- End Message ---
--- Begin Message ---
Version: 4.9.4-2+rm

Dear submitter,

as the package gcc-4.9 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see

The version of this package that was in Debian prior to this removal
can still be found using

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing

Debian distribution maintenance software
Chris Lamb (the ftpmaster behind the curtain)

--- End Message ---

Reply via email to