Bug#1069559: g++-10: std::regex_constants::multiline (C++17) missing in -std=gnu++20
Package: g++-10
Version: 10.2.1-6
Severity: important
X-Debbugs-Cc: um4...@mutluit.com
Dear Maintainer,
the value std::regex_constants::multiline is supposed to be present
in C++17 and later (cf. for example
https://en.cppreference.com/w/cpp/regex/basic_regex/constants ),
but actually it's missing in this compiler version (which supports C++17 as
well even C++20).
Compiler switches used:
OPTS="-Wall -Wextra -W -Wformat -pedantic -pedantic-errors -std=gnu++20
-frecord-gcc-switches"
g++ -g $OPTS blahfoo.cpp -lm -lssl -lcrypto -lz
The compilation error:
"
blahfoo.cpp:5122:59: error: ‘multiline’ is not a member of
‘std::regex_constants’
5122 | if (sOpt == "multiline") { f |= regex_constants::multiline;
continue; }
| ^
Command exited with non-zero status 1
"
$ g++ --version
g++ (Debian 10.2.1-6) 10.2.1 20210110
Expectation:
Since this compiler version supports C++17 (and even C++20), then it should have
the above said missing C++17 constant defined.
-- System Information:
Debian Release: 11.9
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-0.deb11.11-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-10 depends on:
ii gcc-1010.2.1-6
ii gcc-10-base 10.2.1-6
ii libc6 2.31-13+deb11u6
ii libgmp10 2:6.2.1+dfsg-1+deb11u1
ii libisl23 0.23-1
ii libmpc3 1.2.0-1
ii libmpfr6 4.1.0-3
ii libstdc++-10-dev 10.2.1-6
ii libzstd1 1.4.8+dfsg-2.1
ii zlib1g1:1.2.11.dfsg-2+deb11u2
g++-10 recommends no packages.
Versions of packages g++-10 suggests:
pn g++-10-multilib
pn gcc-10-doc
-- no debconf information
Bug#810868: threads: condition_variable or atomic causes _sometimes_ a deadlock
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 1 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
#include
#include
#include
#include
#include
#include
using namespace std;
mutexmtx;
condition_variable cv;
atomic fReady; // init done in main
atomic fQuit; // init done in main
atomic fThreadsOk; // init done in main
void threadfunc(int id)
{
/*
Any thread that intends to wait on condition_variable has to acquire a
unique_lock 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 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 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 < 1; ++i)
{
cout << N << " threads ready to race: ";
// notify threads about work to do
{
unique_lock 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 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.94.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 libmpc31.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
pn gcc-4.9-doc
pn libstdc++6-4.9-dbg
-- no debconf information
Bug#810868: threads: condition_variable or atomic causes _sometimes_ a deadlock
I have been able to locate the bug:
The implementation of the non-lambda version of condition_variable.wait()
in my compiler (g++ (Debian 4.9.2-10) 4.9.2) seems to be buggy;
I guess it is also in the other versions of g++.
One can simulate the buggy behaviour by enabling the 2 ifdef's below.
Then run the executable multiple times until the pgm hangs.
I tested it on a QuadCore-CPU ("AMD A10-5750M APU with Radeon(tm) HD Graphics").
For more info see initial posting.
// test.cpp
// g++ -Wall -O2 -std=gnu++11 test.cpp -lpthread
//
#include
// #include
#include
#include
#include
#include
#include
using namespace std;
mutexmtx;
condition_variable cv;
bool fReady = false;
bool fQuit = false;
void threadfunc(int id)
{
/*
Any thread that intends to wait on condition_variable has to acquire a
unique_lock 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 lck(mtx);
#if 0
// THIS IS BUGGY!
cv.wait(lck);
#else
// THIS IS OK
cv.wait(lck, []{ return fReady || fQuit; });
#endif
if (fQuit) break;
if (!fReady) continue;
// work, ie. process the job
cout << "thread " << id << " has grabbed the job\n";
//...
// notify parent with fReady=false (ie. "job done")
// wakes up also all the other threads
fReady = false;
cv.notify_all();
}
unique_lock lck(mtx);
cout << "thread " << id << " finished\n";
}
int main()
{
const size_t N = 10;
vector threads;
for (size_t i = 0; i < N; ++i)
threads.push_back(thread(threadfunc, i));
for (size_t i = 0; i < 1; ++i)
{
cout << i << " : " << N << " threads ready to race: ";
// notify all threads about work to do
{
unique_lock lck(mtx);
fReady = true;
}
cv.notify_all();
#if 0
// wait till job finished [THIS IS BUGGY!]
{
unique_lock lck(mtx);
while (fReady) cv.wait(lck);
}
#else
// wait till job finished [THIS IS OK]
{
unique_lock lck(mtx);
cv.wait(lck, []{ return !fReady; });
}
#endif
}
// set fQuit and wake up all threads
{
unique_lock lck(mtx);
fQuit = true;
}
cv.notify_all();
// wait till all threads have quit
{
unique_lock lck(mtx);
cout << "join\n";
}
for (auto& th : threads) th.join();
cout << "pgm finished\n";
return 0;
}
// end of test.cpp
