Your message dated Tue, 20 Sep 2016 22:15:11 +0000
with message-id <e1bmtjn-0005qy...@franck.debian.org>
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 ow...@bugs.debian.org
immediately.)
--
810868: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810868
Debian Bug Tracking System
Contact ow...@bugs.debian.org 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
times:
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.
/*
test.cpp
2016-01-13-We
Author: U.Mutlu
condition variable example (but is [sometimes] buggy)
Code adapted from the example at [1]
Question:
How to fix this code?
--> it could be a low-level issue, ie. compiler-, stdlibrary-, or pthread-
issue
What-it-does:
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
Compile:
g++ -Wall -O2 -std=gnu++11 test.cpp -lpthread
Run:
./a.out
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
finishing
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:
[1] http://www.cplusplus.com/reference/condition_variable/condition_variable/
[2] http://en.cppreference.com/w/cpp/thread/condition_variable
*/
#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;
cv.notify_all();
}
}
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;
cv.notify_all();
// wait till job was done
while (fReady) cv.wait(lck);
}
}
// set fQuit and wake up the threads
{
unique_lock<mutex> lck(mtx);
fQuit = true;
cv.notify_all();
}
// 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 https://bugs.debian.org/838316
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.
Debian distribution maintenance software
pp.
Chris Lamb (the ftpmaster behind the curtain)
--- End Message ---