How do I get nicer diagnostic information from boost::exception? - c++

I'm throwing a boost::exception using
BOOST_THROW_EXCEPTION(trace_collector_error_t()
<< boost::errinfo_api_function("ioctl")
<< boost::errinfo_errno(errno)
<< errinfo_trace_params_t(trace_params));
and after
std::cerr << boost::diagnostic_information(e) << std::endl;
I get
: Throw in function trace_config_t set_up_trace(size_t, size_t)
Dynamic exception type: N5boost16exception_detail10clone_implI23trace_collector_error_tEE
std::exception::what: std::exception
[P23errinfo_trace_params_t_] = [ type: 14trace_params_t, size: 16, dump: 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 ]
22, "Invalid argument"[PN5boost21errinfo_api_function_E] = ioctl
I have two questions:
How do I get nicer type names?
How do I get the errinfo_errno to be printed properly?
I'm using GCC 4.6 and Boost 1.55.0.

Well, this is not a answer, but I can't put it into comments w/o breaking formatting completely. So here it is.
I've got the following results with GCC-4.7.2 and Boost-1.53. Update: just checked GCC-4.8.1/Boost-1.53 in Ubuntu 13.10, it works the same way as the code below
#include <errno.h>
#include <boost/exception/all.hpp>
using namespace std;
struct trace_collector_error: virtual std::exception, virtual boost::exception {};
typedef boost::error_info<struct trace_tag_t, int> trace_info;
namespace a {
class A {
public:
A() { clog << __PRETTY_FUNCTION__ << endl; }
void f() {
clog << __PRETTY_FUNCTION__ << endl;
BOOST_THROW_EXCEPTION(trace_collector_error()
<< boost::errinfo_api_function("ioctl")
<< boost::errinfo_errno(errno)
<< trace_info(1)
);
}
};
}
int main(void) {
a::A a;
try {
a.f();
} catch (const trace_collector_error& e) {
std::cerr << boost::diagnostic_information(e) << std::endl;
}
return 0;
}
Output is:
alex#galene tmp/c++/tests $ build/boost_exception_test
a::A::A()
void a::A::f()
/home/alex/tmp/c++/tests/boost_exception_test.cpp(23): Throw in function void a::A::f()
Dynamic exception type: boost::exception_detail::clone_impl
std::exception::what: std::exception
[trace_tag_t*] = 1
[boost::errinfo_errno_*] = 0, "Success"
[boost::errinfo_api_function_*] = ioctl
This is my compiler version/build:
alex#galene tmp/c++/tests $ gcc -v
Using built-in specs.
COLLECT_GCC=i586-alt-linux-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-alt-linux/4.7.2/lto-wrapper
Target: i586-alt-linux
Configured with: ../configure --host=i586-alt-linux --build=i586-alt-linux --target=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --enable-shared --enable-bootstrap --program-suffix=-4.7 --with-slibdir=/lib --with-bugurl=http://bugzilla.altlinux.org --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --enable-multilib --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,fortran,objc,obj-c++,java,ada,go,lto --enable-plugin --enable-java-awt=gtk --with-native-libdir=/usr/lib/gcj-4.7 --with-ecj-jar=/usr/share/java/ecj.jar --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.7-1.5.0.0/jre --enable-libgcj-multifile --disable-libjava-multilib --enable-java-maintainer-mode --with-arch=i586 --with-tune=generic
Thread model: posix
gcc version 4.7.2 20121109 (ALT Linux 4.7.2-alt7) (GCC)
alex#galene tmp/c++/tests $

For those struggling: switching to Boost version 1.53 fixed the problem.

Related

Using short string optimization appears to be slower than allocations in gcc 9.4.0

I'm testing the following piece of code
#include <string>
int main(int argc, const char *argv[])
{
const size_t size = strtoull(argv[1], nullptr, 10);
for (int i = 0; i < 100000000; ++i)
{
std::string str;
str.reserve(size);
for (size_t j = 0; j < size; ++j)
{
str += 'x';
}
}
return 0;
}
I compile it with -O3
g++ string-append.cpp -O3 -o string-append
Now when running with parameter 15 the program appears slower then when running with parameter 16.
$ time ./string-append 15
real 0m4.342s
user 0m4.342s
sys 0m0.000s
$ time ./string-append 16
real 0m3.112s
user 0m3.112s
sys 0m0.000s
I have verified with valgrind that:
15: no allocations for the string
16: 100M allocations and 100M deallocations
Using printouts I verified that:
15: str.c_str() returns always the same address
16: str.c_str() returns different address every time
Using perf I verified that 16 gives more:
L1 cache loads
L1 cache stores
L1 cache misses
branches
branches misses
instructions (almost twice more)
What is the reason that the code works faster for size 16?
Compiler is gcc version 9.4.0.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.4.0-1ubuntu1~20.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
Checked on Clang13 - it does not seem to have this problem.

Compiler bug? Lambda capture behavior affected by GCC optimization level

#include <functional>
#include <stdio.h>
int main()
{
std::function<void(int)> func;
int capture = 1234;
printf("outside capture=%d\n", capture);
if (capture) {
func =
[capture](int x) {
printf("inside capture=%d\n", capture);
};
func(0);
}
}
Compile (with -Os, -O2 or -O3) and execute it, result is
outside capture=1234
inside capture=67213
Compile with -O1 or without -O?, the result is (this is what I expect)
outside capture=1234
inside capture=1234
Is there any thing wrong? I doubt this is compiler or C++ standard library bug.
Could you give me some comments?
$ gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/opt/arm/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/6.1.1/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/snapshots/gcc-linaro-6.1-2016.08/configure SHELL=/bin/bash --with-mpc=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-mpfr=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gmp=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu --with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap --with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-c99 --enable-gnu-indirect-function --with-tune=cortex-a9 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-multilib --enable-multiarch --with-build-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/sysroots/arm-linux-gnueabihf --enable-lto --enable-linker-build-id --enable-long-long --enable-shared --with-sysroot=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran,lto --enable-checking=release --disable-bootstrap --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/tcwg-buildslave/workspace/tcwg-make-release/label/docker-trusty-amd64-tcwg/target/arm-linux-gnueabihf/_build/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 6.1.1 20160711 (Linaro GCC 6.1-2016.08)
This issue also can be verified on x86_64 by following shell commands
sudo apt-get -y install qemu-user
wget https://releases.linaro.org/components/toolchain/binaries/6.1-2016.08/arm-linux-gnueabihf/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz
tar -xf gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz
cat <<EOF > test.cpp
#include <functional>
#include <stdio.h>
int main()
{
std::function<void(int)> func;
int capture = 1234;
printf("outside capture=%d\n", capture);
if (capture) {
func =
[capture](int x) {
printf("inside capture=%d\n", capture);
};
func(0);
}
}
EOF
gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++ -Os test.cpp
qemu-arm gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib/ld-linux-armhf.so.3 --library-path gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib ./a.out
The result is
outside capture=1234
inside capture=-161318064

How to pick minimal buffer size for number to string converting?

I try to make minimal buffer for std::snprintf to convert uint64_t to std::string and found error in converted string for big values
#include <cstdio>
#include <inttypes.h>
#include <limits>
#include <string>
#include <cstdint>
// assume this is maximum string size to represent any unsigned integer
// with 1 extra byte for string terminating null character
const std::size_t MAX_UINT64_WIDTH =
std::numeric_limits<std::uint64_t>::digits10 + 1;
int main(int, char**)
{
uint64_t value = 10244450920698242790ULL;
const std::string svalue = "10244450920698242790";
std::string str;
char buf[MAX_UINT64_WIDTH];
auto l = std::snprintf(buf, MAX_UINT64_WIDTH, "%" PRIu64, value);
if (l > 0) {
str.assign(buf, buf + l);
}
assert(svalue == str); //assertion failed, the last character '0' (0x30) is replaced with '\0' (0x00)
return 0;
}
Then I found that assert(21 == MAX_UINT64_WIDTH); also fails. And finally minimal program shows up error is
#include <limits>
#include <iostream>
#include <string>
#include <cstdint>
int main(int, char**) {
std::cout << std::numeric_limits<std::uint64_t>::max() << std::endl;
std::cout << std::numeric_limits<std::uint64_t>::digits10 << std::endl;
std::cout << std::to_string(std::numeric_limits<std::uint64_t>::max()).size() << std::endl;
return 0;
}
user#host:~$ g++ --std=c++11 -o check check.cpp
user#host:~$ ./check
18446744073709551615
19
20
user#host:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.5' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
Update
I misuse library digits10 so I rename my question.
digits10 is the number of digits of a number that you can "safely" store in that type. If for example std::numeric_limits<std::uint64_t>::max() is 18446744073709551615 then you cannot store a number with same number of digits and all digits equal to 9 in an uint64_t.
Lets say, if the max has N digits, then digits10 is typically N-1 (unless max is 99999...9999).

Is that a feature or a bug of clang c++11 std::regex_match?

I noted that a regular expression, containing two patterns with OR condition, do not match a sample string if the first pattern is a beginning part of the second pattern (tested on clang 3.5 and clang 3.8):
std::regex_match("ab", std::regex("(ab|a)")) == true
but
std::regex_match("ab", std::regex("(a|ab)")) == false
I think true is logically correct in both cases.
Clang & OSX:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ clang++ -v
Apple LLVM version 8.1.0 (clang-802.0.41)
Target: x86_64-apple-darwin16.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ clang++ ./test.cpp -o test
$ ./test
0
1
Clang & FreeBSD:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ clang++ -v
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
$ clang++ ./test.cpp -o test
$ ./test
0
1
Linux & GCC:
$ cat > test.cpp
#include <string>
#include <regex>
#include <iostream>
int main() {
std::cout << std::regex_match("ab", std::regex("(a|ab)")) << std::endl;
std::cout << std::regex_match("ab", std::regex("(ab|a)")) << std::endl;
return 0;
}
^C
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.1-2ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.1 20160904 (Ubuntu 5.4.1-2ubuntu1~16.04)
$ g++ -std=gnu++11 ./test.cpp -o test
$ ./test
1
1
ECMAScript (the default regex syntax) attempts to match the alternatives in order, stopping at the first success, which means that in ordinary searching (a la regex_search) the regex a|ab never matches the whole ab; it always matches just the a part.
The standard was ambiguous about what regex_match was supposed to do in this case, leading to implementation divergence. See LWG issue 2273 for the competing interpretations. Eventually the standard was amended (see the resolution of that issue) to make clear that regex_match only considers potential matches that match the entire input sequence, as the example added to the standard makes clear:
std::regex re("Get|GetValue");
std::cmatch m;
regex_search("GetValue", m, re); // returns true, and m[0] contains "Get"
regex_match ("GetValue", m, re); // returns true, and m[0] contains "GetValue"
The original <regex> implementation in libc++ used the other interpretation, however, and it simply wasn't updated to match the resolution until recently. Clang 4.0 now prints 1 1.

Is std::async broken in gcc 4.7 on linux? [closed]

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm testing std::async in isolation before using it in real code, to verify that it works correctly on my platform (which is ubuntu 12.10 64-bit).
It works (somewhat rarely) and usually just hangs. If it works for you, don't jump to conclusions. Try a few more times, it will probably hang.
If I remove the pthread_mutex test, it doesn't hang. This is the smallest code I can get to reproduce the hang. Is there some reason that you can't mix C pthread code with c++ async code?
#include <iostream>
#include <pthread.h>
#include <chrono>
#include <future>
#include <iomanip>
#include <sstream>
#include <type_traits>
template<typename T>
std::string format_ns(T &&value)
{
std::stringstream s;
if (std::is_floating_point<T>::value)
s << std::setprecision(3);
if (value >= 1000000000)
s << value / 1000000000 << "s";
else if (value >= 1000000)
s << value / 1000000 << "ms";
else if (value >= 1000)
s << value / 1000 << "us";
else
s << value << "ns";
return s.str();
}
template<typename F>
void test(const std::string &msg, int iter, F &&lambda)
{
std::chrono::high_resolution_clock clock;
auto st = clock.now();
int i;
for (i = 0; i < iter; ++i)
lambda();
auto en = clock.now();
std::chrono::nanoseconds dur = std::chrono::duration_cast<
std::chrono::nanoseconds>(en-st);
std::cout << msg << format_ns(dur.count() / i) << std::endl;
}
int test_pthread_mutex()
{
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
test("pthread_mutex_lock/pthread_mutex_unlock: ", 1000000000,
[&]()
{
pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);
});
pthread_mutex_destroy(&m);
return 0;
}
int test_async()
{
test("async: ", 100,
[&]()
{
auto asy = std::async(std::launch::async, [](){});
asy.get();
});
return 0;
}
int main()
{
test_pthread_mutex();
test_async();
}
Here is the build command line:
g++ -Wextra -Wall --std=c++11 -pthread mutexperf/main.cpp
There are no build output messages.
Here is the output of g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
I tried it on a few different computers and found that it indeed worked fine like #johan commented. I investigated the machine I was using and found evidence that the hard drive is beginning to fail. It has some bad sectors and also saw dmesg report several "hard resets" of the HDD after an unusual 4 second freeze. Odd, I hadn't seen any issues before I posted the question. It's probably some subtle/intermittent corruption when compiling/linking or perhaps when loading the executable.
[44242.380936] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x800000 action 0x6 frozen
[44242.380942] ata3.00: irq_stat 0x08000000, interface fatal error
[44242.380946] ata3: SError: { LinkSeq }
[44242.380950] sr 2:0:0:0: CDB:
[44242.380952] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[44242.380965] ata3.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
[44242.380965] res 50/00:03:00:08:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[44242.380968] ata3.00: status: { DRDY }
[44242.380974] ata3: hard resetting link
[44242.700025] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[44242.704849] ata3.00: configured for UDMA/100
[44242.720055] ata3: EH complete
[44970.117542] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x800100 action 0x6 frozen
[44970.117547] ata3.00: irq_stat 0x08000000, interface fatal error
[44970.117551] ata3: SError: { UnrecovData LinkSeq }
[44970.117555] sr 2:0:0:0: CDB:
[44970.117557] Get event status notification: 4a 01 00 00 10 00 00 00 08 00
[44970.117570] ata3.00: cmd a0/00:00:00:08:00/00:00:00:00:00/a0 tag 0 pio 16392 in
[44970.117570] res 50/00:03:00:08:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[44970.117573] ata3.00: status: { DRDY }
[44970.117579] ata3: hard resetting link
[44970.436662] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[44970.443159] ata3.00: configured for UDMA/100
[44970.456639] ata3: EH complete
Thanks to anyone who spent time looking at my issue!
Have you try to copy the mutex rather than pass by reference in lambda?
int test_pthread_mutex()
{
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
test("pthread_mutex_lock/pthread_mutex_unlock: ", 1000000000,
[=]()
{
pthread_mutex_lock(&m);
pthread_mutex_unlock(&m);
});
pthread_mutex_destroy(&m);
return 0;
}