Undetected platform due to Clang address' sanitizer? - memory-leaks

I use clang 14.0.5 and link against what is provided by ocl-icd-devel (v 2.3.1) on a fedora 36 box. I am running on a x86-64 CPU attached to a gtx1050ti and the nvidia-smi report is given below:
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 525.85.05 Driver Version: 525.85.05 CUDA Version: 12.0 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|===============================+======================+======================|
| 0 NVIDIA GeForce ... Off | 00000000:01:00.0 Off | N/A |
| N/A 39C P8 N/A / N/A | 3MiB / 4096MiB | 0% Default |
| | | N/A |
+-------------------------------+----------------------+----------------------+
Assuming the code below:
#include <CL/cl.h>
#include <iostream>
int main() {
::cl_uint platform_count;
::clGetPlatformIDs(0, NULL, &platform_count);
std::cout << platform_count << "\n";
}
The clGetPlatformIDs function does not fail.
Compiled with clang++ test.cc -lOpenCL leads to the following output:
2
I indeed have two OpenCL platforms, Nvidia and Mesa, as properly reported by clinfo. This is the expected behavior.
Now, compiling with clang++ test.cc -lOpenCL -fsanitize=address leads to the following output:
1
=================================================================
==119688==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1120 byte(s) in 20 object(s) allocated from:
#0 0x4cfd97 in __interceptor_calloc (/../test+0x4cfd97) (BuildId: 66d5be805632cad14f58fab06c64ebed85d7da00)
#1 0x7f6d3ce7fad9 (/lib64/libnvidia-opencl.so.1+0x27fad9) (BuildId: ca94830f39da5d51a55258eb21cc484556b036b5)
Indirect leak of 1920 byte(s) in 20 object(s) allocated from:
#0 0x4cfd97 in __interceptor_calloc (/../test+0x4cfd97) (BuildId: 66d5be805632cad14f58fab06c64ebed85d7da00)
#1 0x7f6d3ce7faf4 (/lib64/libnvidia-opencl.so.1+0x27faf4) (BuildId: ca94830f39da5d51a55258eb21cc484556b036b5)
...
<cut for brievety>
This issue does not shows up if I target x86 (clang triple: i686--linux-), that is, I get two platforms. Though the sanitizer still catches potential memory leaks:
================================================================
==119438==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 880 byte(s) in 20 object(s) allocated from:
#0 0x8120c0b in __interceptor_calloc (/../test+0x8120c0b) (BuildId: 9b9e395397d659c010914e0c90e5d710fc95826d)
#1 0xf36bea17 (/lib/libnvidia-opencl.so.1+0x2bea17) (BuildId: 9ea2f83814d7ff837ade8227643aea1f94ba6908)
#2 0xf36944c3 (/lib/libnvidia-opencl.so.1+0x2944c3) (BuildId: 9ea2f83814d7ff837ade8227643aea1f94ba6908)
#3 0xf36a07a9 (/lib/libnvidia-opencl.so.1+0x2a07a9) (BuildId: 9ea2f83814d7ff837ade8227643aea1f94ba6908)
#4 0xf351358c (/lib/libnvidia-opencl.so.1+0x11358c) (BuildId: 9ea2f83814d7ff837ade8227643aea1f94ba6908)
...
<cut for brievety>
The same code in C leads to:
#include <CL/cl.h>
#include <stdio.h>
int main() {
cl_uint platform_count;
if(CL_SUCCESS == clGetPlatformIDs(0, NULL, &platform_count))
printf("%d\n", platform_count);
}
Which also fails but in a different way:
AddressSanitizer: CHECK failed: asan_interceptors.cpp:321 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0) (tid=72340)
#0 0x4d7a5a in __asan::CheckUnwind() asan_rtl.cpp.o
#1 0x4f3a0d in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/.../test+0x4f3a0d) (BuildId: 957a08089740f3382763ab916b58469c68e1b465)
#2 0x444804 in __interceptor___cxa_throw (/.../test+0x444804) (BuildId: 957a08089740f3382763ab916b58469c68e1b465)
#3 0x7faa03669d28 (/lib64/libMesaOpenCL.so.1+0x30d28) (BuildId: 810b5bd27dbdbfd1325bb221f29c97960f5b6183)
#4 0x7faa036a3699 (/lib64/libMesaOpenCL.so.1+0x6a699) (BuildId: 810b5bd27dbdbfd1325bb221f29c97960f5b6183)
#5 0x7faa0366d77c (/lib64/libMesaOpenCL.so.1+0x3477c) (BuildId: 810b5bd27dbdbfd1325bb221f29c97960f5b6183)
#6 0x7faa05df1f7d in call_init /usr/src/debug/glibc-2.35-22.fc36.x86_64/elf/dl-init.c:70:3
#7 0x7faa05df1f7d in call_init /usr/src/debug/glibc-2.35-22.fc36.x86_64/elf/dl-init.c:26:1
#8 0x7faa05df206b in _dl_init /usr/src/debug/glibc-2.35-22.fc36.x86_64/elf/dl-init.c:117:5
#9 0x7faa05b54773 in _dl_catch_exception (/lib64/libc.so.6+0x154773) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#10 0x7faa05df9195 in dl_open_worker /usr/src/debug/glibc-2.35-22.fc36.x86_64/elf/dl-open.c:808:5
#11 0x7faa05b5471d in _dl_catch_exception (/lib64/libc.so.6+0x15471d) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#12 0x7faa05df952b in _dl_open /usr/src/debug/glibc-2.35-22.fc36.x86_64/elf/dl-open.c:884:17
#13 0x7faa05a88edb in dlopen_doit (/lib64/libc.so.6+0x88edb) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#14 0x7faa05b5471d in _dl_catch_exception (/lib64/libc.so.6+0x15471d) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#15 0x7faa05b547d2 in _dl_catch_error (/lib64/libc.so.6+0x1547d2) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#16 0x7faa05a889ae in _dlerror_run (/lib64/libc.so.6+0x889ae) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#17 0x7faa05a88f90 in dlopen##GLIBC_2.34 (/lib64/libc.so.6+0x88f90) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#18 0x46c007 in __interceptor_dlopen.part.0 asan_interceptors.cpp.o
#19 0x7faa05dab8a5 (/lib64/libOpenCL.so.1+0xc8a5) (BuildId: 0ebfaaa96fdffe2b1aa490dea42c38ae14275426)
#20 0x7faa05daee70 (/lib64/libOpenCL.so.1+0xfe70) (BuildId: 0ebfaaa96fdffe2b1aa490dea42c38ae14275426)
#21 0x7faa05db0f73 in clGetPlatformIDs (/lib64/libOpenCL.so.1+0x11f73) (BuildId: 0ebfaaa96fdffe2b1aa490dea42c38ae14275426)
#22 0x511689 in main (/.../test+0x511689) (BuildId: 957a08089740f3382763ab916b58469c68e1b465)
#23 0x7faa05a2950f in __libc_start_call_main (/lib64/libc.so.6+0x2950f) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#24 0x7faa05a295c8 in __libc_start_main#GLIBC_2.2.5 (/lib64/libc.so.6+0x295c8) (BuildId: 8257ee907646e9b057197533d1e4ac8ede7a9c5c)
#25 0x41c304 in _start (/.../test+0x41c304) (BuildId: 957a08089740f3382763ab916b58469c68e1b465)
Finally, if I use the undefined sanitizer, I do not get the platform count issue nor reported undefined behavior.

Related

'/usr/bin/gcc' failed with exit code 1 while installing cryptography package python on Python:3.7-alpine

Error stack trace
creating build/temp.linux-aarch64-cpython-37/build
#9 13.81 creating build/temp.linux-aarch64-cpython-37/build/temp.linux-aarch64-cpython-37
#9 13.81 gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -DTHREAD_STACK_SIZE=0x100000 -fPIC -I/usr/local/include/python3.7m -c build/temp.linux-aarch64-cpython-37/_openssl.c -o build/temp.linux-aarch64-cpython-37/build/temp.linux-aarch64-cpython-37/_openssl.o -Wconversion -Wno-error=sign-conversion
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:2183:7: error: 'EVP_PKEY_CTX_set_rsa_oaep_md' redeclared as different kind of symbol
#9 13.81 2183 | int (*EVP_PKEY_CTX_set_rsa_oaep_md)(EVP_PKEY_CTX *, EVP_MD *) = NULL;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 In file included from /usr/include/openssl/x509.h:36,
#9 13.81 from /usr/include/openssl/ct.h:29,
#9 13.81 from build/temp.linux-aarch64-cpython-37/_openssl.c:636:
#9 13.81 /usr/include/openssl/rsa.h:158:5: note: previous declaration of 'EVP_PKEY_CTX_set_rsa_oaep_md' with type 'int(EVP_PKEY_CTX *, const EVP_MD *)' {aka 'int(struct evp_pkey_ctx_st *, const struct evp_md_st *)'}
#9 13.81 158 | int EVP_PKEY_CTX_set_rsa_oaep_md(EVP_PKEY_CTX *ctx, const EVP_MD *md);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:2190:7: error: 'EVP_PKEY_CTX_set0_rsa_oaep_label' redeclared as different kind of symbol
#9 13.81 2190 | int (*EVP_PKEY_CTX_set0_rsa_oaep_label)(EVP_PKEY_CTX *, unsigned char *,
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 /usr/include/openssl/rsa.h:164:5: note: previous declaration of 'EVP_PKEY_CTX_set0_rsa_oaep_label' with type 'int(EVP_PKEY_CTX *, void *, int)' {aka 'int(struct evp_pkey_ctx_st *, void *, int)'}
#9 13.81 164 | int EVP_PKEY_CTX_set0_rsa_oaep_label(EVP_PKEY_CTX *ctx, void *label, int llen);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function 'Cryptography_pem_password_cb':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:2943:37: warning: conversion to 'size_t' {aka 'long unsigned int'} from 'int' may change the sign of the result [-Wsign-conversion]
#9 13.81 2943 | memcpy(buf, st->password, st->length);
#9 13.81 | ~~^~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_const_CRYPTO_MEM_CHECK_DISABLE':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7085:12: error: 'CRYPTO_MEM_CHECK_DISABLE' undeclared (first use in this function); did you mean '_cffi_const_CRYPTO_MEM_CHECK_DISABLE'?
#9 13.81 7085 | int n = (CRYPTO_MEM_CHECK_DISABLE) <= 0;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 | _cffi_const_CRYPTO_MEM_CHECK_DISABLE
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7085:12: note: each undeclared identifier is reported only once for each function it appears in
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_const_CRYPTO_MEM_CHECK_ENABLE':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7092:12: error: 'CRYPTO_MEM_CHECK_ENABLE' undeclared (first use in this function); did you mean '_cffi_const_CRYPTO_MEM_CHECK_ENABLE'?
#9 13.81 7092 | int n = (CRYPTO_MEM_CHECK_ENABLE) <= 0;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 | _cffi_const_CRYPTO_MEM_CHECK_ENABLE
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_const_CRYPTO_MEM_CHECK_OFF':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7099:12: error: 'CRYPTO_MEM_CHECK_OFF' undeclared (first use in this function)
#9 13.81 7099 | int n = (CRYPTO_MEM_CHECK_OFF) <= 0;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_const_CRYPTO_MEM_CHECK_ON':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7106:12: error: 'CRYPTO_MEM_CHECK_ON' undeclared (first use in this function)
#9 13.81 7106 | int n = (CRYPTO_MEM_CHECK_ON) <= 0;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_const_EVP_R_KEYGEN_FAILURE':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:7886:12: error: 'EVP_R_KEYGEN_FAILURE' undeclared (first use in this function)
#9 13.81 7886 | int n = (EVP_R_KEYGEN_FAILURE) <= 0;
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_BIO_s_datagram':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:13688:10: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 13688 | return BIO_s_datagram();
#9 13.81 | ^~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_BIO_s_datagram':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:13699:12: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 13699 | { result = BIO_s_datagram(); }
#9 13.81 | ^
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_BIO_s_mem':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:13714:10: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 13714 | return BIO_s_mem();
#9 13.81 | ^~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_BIO_s_mem':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:13725:12: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 13725 | { result = BIO_s_mem(); }
#9 13.81 | ^
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_CRYPTO_mem_ctrl':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:16642:10: warning: implicit declaration of function 'CRYPTO_mem_ctrl'; did you mean 'CRYPTO_memcmp'? [-Wimplicit-function-declaration]
#9 13.81 16642 | return CRYPTO_mem_ctrl(x0);
#9 13.81 | ^~~~~~~~~~~~~~~
#9 13.81 | CRYPTO_memcmp
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_ERR_GET_FUNC':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:25626:10: warning: implicit declaration of function 'ERR_GET_FUNC'; did you mean 'ERR_GET_LIB'? [-Wimplicit-function-declaration]
#9 13.81 25626 | return ERR_GET_FUNC(x0);
#9 13.81 | ^~~~~~~~~~~~
#9 13.81 | ERR_GET_LIB
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_FIPS_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:31224:10: warning: implicit declaration of function 'FIPS_mode' [-Wimplicit-function-declaration]
#9 13.81 31224 | return FIPS_mode();
#9 13.81 | ^~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_FIPS_mode_set':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:31250:10: warning: implicit declaration of function 'FIPS_mode_set' [-Wimplicit-function-declaration]
#9 13.81 31250 | return FIPS_mode_set(x0);
#9 13.81 | ^~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_OCSP_resp_get0_certs':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:34338:10: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 34338 | return OCSP_resp_get0_certs(x0);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_OCSP_resp_get0_certs':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:34361:12: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
#9 13.81 34361 | { result = OCSP_resp_get0_certs(x0); }
#9 13.81 | ^
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_add_extra_chain_cert':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:40821:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 40821 | return SSL_CTX_add_extra_chain_cert(x0, x1);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_add_extra_chain_cert':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:40859:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 40859 | { result = SSL_CTX_add_extra_chain_cert(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_get_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:41289:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 41289 | return SSL_CTX_get_mode(x0);
#9 13.81 | ^~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_get_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:41312:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 41312 | { result = SSL_CTX_get_mode(x0); }
#9 13.81 | ^~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_get_session_cache_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:41403:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 41403 | return SSL_CTX_get_session_cache_mode(x0);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_get_session_cache_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:41426:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 41426 | { result = SSL_CTX_get_session_cache_mode(x0); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_set_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43067:10: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43067 | return SSL_CTX_set_mode(x0, x1);
#9 13.81 | ^~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43067:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_set_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43100:14: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43100 | { result = SSL_CTX_set_mode(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43100:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 In file included from build/temp.linux-aarch64-cpython-37/_openssl.c:798:
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_set_session_cache_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43463:45: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43463 | return SSL_CTX_set_session_cache_mode(x0, x1);
#9 13.81 | ^~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43463:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43463 | return SSL_CTX_set_session_cache_mode(x0, x1);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_set_session_cache_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43496:49: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43496 | { result = SSL_CTX_set_session_cache_mode(x0, x1); }
#9 13.81 | ^~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43496:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43496 | { result = SSL_CTX_set_session_cache_mode(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_set_tmp_dh':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43869:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43869 | return SSL_CTX_set_tmp_dh(x0, x1);
#9 13.81 | ^~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_set_tmp_dh':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43907:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43907 | { result = SSL_CTX_set_tmp_dh(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_CTX_set_tmp_ecdh':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43922:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43922 | return SSL_CTX_set_tmp_ecdh(x0, x1);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_CTX_set_tmp_ecdh':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:43960:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 43960 | { result = SSL_CTX_set_tmp_ecdh(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_SESSION_get_ticket_lifetime_hint':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:44675:10: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 44675 | return SSL_SESSION_get_ticket_lifetime_hint(x0);
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_SESSION_get_ticket_lifetime_hint':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:44698:14: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 44698 | { result = SSL_SESSION_get_ticket_lifetime_hint(x0); }
#9 13.81 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_get_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:46091:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 46091 | return SSL_get_mode(x0);
#9 13.81 | ^~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_get_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:46114:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 46114 | { result = SSL_get_mode(x0); }
#9 13.81 | ^~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_SSL_set_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:47950:10: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 47950 | return SSL_set_mode(x0, x1);
#9 13.81 | ^~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:47950:10: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_f_SSL_set_mode':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:47983:14: warning: conversion to 'long int' from 'long unsigned int' may change the sign of the result [-Wsign-conversion]
#9 13.81 47983 | { result = SSL_set_mode(x0, x1); }
#9 13.81 | ^~~~~~~~~~~~
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:47983:14: warning: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Wsign-conversion]
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_EVP_PKEY_CTX_set_rsa_oaep_md':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:28273:1: warning: control reaches end of non-void function [-Wreturn-type]
#9 13.81 28273 | }
#9 13.81 | ^
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c: In function '_cffi_d_EVP_PKEY_CTX_set0_rsa_oaep_label':
#9 13.81 build/temp.linux-aarch64-cpython-37/_openssl.c:28161:1: warning: control reaches end of non-void function [-Wreturn-type]
#9 13.81 28161 | }
#9 13.81 | ^
#9 13.81 error: command '/usr/bin/gcc' failed with exit code 1
#9 13.81 [end of output]
#9 13.81
#9 13.81 note: This error originates from a subprocess, and is likely not a problem with pip.
#9 13.81 ERROR: Failed building wheel for cryptography
#9 13.81 Building wheel for cffi (setup.py): started
#9 17.02 Building wheel for cffi (setup.py): finished with status 'done'
#9 17.02 Created wheel for cffi: filename=cffi-1.15.1-cp37-cp37m-linux_aarch64.whl size=194157 sha256=4d9b4b781f90c9a48ba70d4b20376e205e3de1ad40ffc80a65e7b1760e68a019
#9 17.02 Stored in directory: /tmp/pip-ephem-wheel-cache-gz78zwhy/wheels/a1/3b/8e/0d937b639299138f2af58408c94c78bb6c18839c57d0ad8671
#9 17.02 Successfully built cffi
#9 17.02 Failed to build cryptography
#9 17.02 ERROR: Could not build wheels for cryptography, which is required to install pyproject.toml-based projects
Dockerfile
`
FROM python:3.7-alpine
RUN apk add libpq libxml2-dev libxslt-dev
RUN apk add --no-cache libffi-dev postgresql-dev gcc python3-dev musl-dev gfortran build-base wget freetype-dev libpng-dev openblas-dev mariadb-connector-c-dev \
# && ln -s /usr/include/locale.h /usr/include/xlocale.h
COPY requirements.txt requirements.txt
RUN /usr/local/bin/python3 -m pip install --no-cache --upgrade pip \
&& pip3 install --no-cache -r requirements.txt
COPY /crawlers /crawlers
COPY /config /config
COPY /src ./src
Copy credentials.storage credentials.storage
CMD python -m src.app --service import_prices --config ./src/config/docker_config.yml --store 1 --channel medizinfuchs --all True
`
I would like to install cryptography==2.4.2.
Things I've done already:
Tried to install later versions of cryptography (didn't work)
Tried fixing the version of pip when it worked (still didn't work)
added dependencies based here (didn't work)
Tried using other versions of Python (3.8)
I'm just torn on why this suddenly broke.
Solution
use crytography==3.4
this would require to add the following packages
$ sudo apk add gcc musl-dev python3-dev libffi-dev openssl-dev cargo
from cryptography documentation
My final Dockerfile looked like this:
FROM python:3.7-alpine
RUN apk add libpq libxml2-dev libxslt-dev
RUN apk add --no-cache libffi-dev postgresql-dev gcc g++ python3-dev musl-dev linux-headers make libc-dev openssl-dev cargo gfortran build-base wget freetype-dev libpng-dev openblas-dev mariadb-connector-c-dev \
&& ln -s /usr/include/locale.h /usr/include/xlocale.h
COPY requirements.txt requirements.txt
RUN /usr/local/bin/python3 -m pip install --no-cache --upgrade pip \
&& pip3 install -r requirements.txt
COPY /crawlers /crawlers
COPY /config /config
COPY /src ./src
Copy credentials.storage credentials.storage
CMD python -m src.app --service import_prices --config ./src/config/docker_config.yml --store 1 --channel medizinfuchs --all True

Prevent PIN_Backtrace() Unsuccessful Exit

I have a pintool that has calls to PIN_Backtrace(). It seems that libunwind does not support some registers in x86_64 and this leads to the following error message and an abnormal exit:
libunwind: uint64_t libunwind::Registers_x86_64::getRegister(int) const Source/bionic/libunwind/src/Registers.hpp:342 - unsupported x86_64 register
Aborted
I want the program to continue even with these errors. What is the most efficient way to handle this situation?
I debugged my pintool using gdb. Here is the backtrace when abort() is received by the debugger:
(gdb) bt
#0 0x00007ffff726c22b in ?? ()
#1 0x00007fffeca88730 in ?? ()
#2 0x00007ffff726c363 in ?? ()
#3 0x0000000000005386 in ?? ()
#4 0x0000000000000001 in ?? ()
#5 0x0000000000000000 in ?? ()
info proc mapping shows the address ranges as follows:
...
0x7fffeea3a000 0x7ffff71fb000 0x87c1000 0x0
0x7ffff71fb000 0x7ffff7283000 0x88000 0x0 /home/ahmad/Programs/pin-3.7-97619-g0d0c92f4f-gcc-linux/intel64/runtime/pincrt/libc-dynamic.so
0x7ffff7283000 0x7ffff7284000 0x1000 0x0
0x7ffff7284000 0x7ffff7286000 0x2000 0x88000 /home/ahmad/Programs/pin-3.7-97619-g0d0c92f4f-gcc-linux/intel64/runtime/pincrt/libc-dynamic.so
...
and
...
0x7fffe1687000 0x7fffec287000 0xac00000 0x0
0x7fffec287000 0x7fffed28e000 0x1007000 0x0
0x7fffed28e000 0x7fffedb6a000 0x8dc000 0x0
...
It seems that the libunwind library used by Pin is a special one exlusive to PinCRT. This can be seen in the info /proc/<PID>/maps output for the pintool:
...
7ffff7e33000-7ffff7e45000 r-xp 00000000 08:13 466277 /home/ahmad/Programs/pin-3.7-97619-g0d0c92f4f-gcc-linux/intel64/runtime/pincrt/libunwind-dynamic.so
7ffff7e45000-7ffff7e46000 r--p 00011000 08:13 466277 /home/ahmad/Programs/pin-3.7-97619-g0d0c92f4f-gcc-linux/intel64/runtime/pincrt/libunwind-dynamic.so
7ffff7e46000-7ffff7e47000 rw-p 00012000 08:13 466277 /home/ahmad/Programs/pin-3.7-97619-g0d0c92f4f-gcc-linux/intel64/runtime/pincrt/libunwind-dynamic.so
...

gdb debugging of core.# file - getting the full command which caused the crash

I have some complicated problem (by complicated I mean that I couldn't find a solution within a few hours of researching) and the problem is:
I submitted large amount of scripts to run (on an SGE cluster), some of those scripts generated core.# files (core dump files). I figured I could open those files with gdb, now when I simply open the core.# file I see this:
(the last few lines of the gdb output)
Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004a554b in ?? ()
"/4thExp/core.82912" is a core file.
Please specify an executable to debug.
Now to my question - I need to find what was the arguments to the program that caused the crash.
The output mentioned above shows only the beginning of the command that caused the crash: "Core was generated by `/groups/nshomron/artemd/tools/graphmap/bin/Linux-x64/graphmap align --overlappe'."
If I could see the rest of the command I would solve my problem, but after hours of searching online and checking gdb manual I couldn't find anything useful. I tried loading gdb with the program that caused the crash "gdb ..../graphmap core.#" but still I got only the beginning of the faulty command and couldn't get anything else.
Any help suggestion would be very appreciated.
Update: As the user #ks1322 suggested - I looked closely at the threads.
First I executed "info threads" and got the output:
(gdb) info threads
24 Thread 0x2b29409bd700 (LWP 82927) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
23 Thread 0x2b29401b9700 (LWP 82923) 0x00000031d00f820e in __lll_lock_wait_private () from /lib64/libc.so.6
* 22 Thread 0x2b29403ba700 (LWP 82924) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
21 Thread 0x2b29413c2700 (LWP 82932) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
20 Thread 0x2b293fbb6700 (LWP 82920) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
19 Thread 0x2b293fdb7700 (LWP 82921) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
18 Thread 0x2b2940bbe700 (LWP 82928) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
17 Thread 0x2b293f3b2700 (LWP 82916) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
16 Thread 0x2b29411c1700 (LWP 82931) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
15 Thread 0x2b2940dbf700 (LWP 82929) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
14 Thread 0x2b29419c5700 (LWP 82935) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
13 Thread 0x2b293efb0700 (LWP 82914) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
12 Thread 0x2b293f7b4700 (LWP 82918) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
11 Thread 0x2b29407bc700 (LWP 82926) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
10 Thread 0x2b293f9b5700 (LWP 82919) 0x00000031d00f820e in __lll_lock_wait_private () from /lib64/libc.so.6
9 Thread 0x2b29415c3700 (LWP 82933) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
8 Thread 0x2b29405bb700 (LWP 82925) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
7 Thread 0x2b292ea08be0 (LWP 82912) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
6 Thread 0x2b293ffb8700 (LWP 82922) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
5 Thread 0x2b293edaf700 (LWP 82913) 0x00000031d0045063 in vfprintf () from /lib64/libc.so.6
4 Thread 0x2b2940fc0700 (LWP 82930) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
3 Thread 0x2b293f1b1700 (LWP 82915) 0x00000031d00ac6aa in times () from /lib64/libc.so.6
2 Thread 0x2b29417c4700 (LWP 82934) 0x0000000000412bd6 in obtainAlignment(unsigned char const*, unsigned char const*, int, unsigned char const*, unsigned char const*, int, int, int, unsigned char**, int*) ()
1 Thread 0x2b293f5b3700 (LWP 82917) 0x00000000004a554b in GraphMap::ProcessKmerCacheFriendly_(signed char*, long, ScoreRegistry*, MappingData*, Index*, SingleSequence const*, ProgramParameters const*) ()
It didn't tell me very much so I continued to look for a "main thread". I switched to each thread, one by one, and executed "info stack". The only thread containing something relevant was thread 7. the info stack output:
(gdb) thread 7
[Switching to thread 7 (Thread 0x2b292ea08be0 (LWP 82912))]#0 0x00000031d00ac6aa in times () from /lib64/libc.so.6
(gdb) info stack
#0 0x00000031d00ac6aa in times () from /lib64/libc.so.6
#1 0x00000031d009bcba in clock () from /lib64/libc.so.6
#2 0x00000000004ccaed in GraphMap::RegionSelectionNoCopy_(long, MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*) ()
#3 0x00000000004c3544 in GraphMap::ProcessRead(MappingData*, std::vector<Index*, std::allocator<Index*> >, SingleSequence const*, ProgramParameters const*, EValueParams const*) ()
#4 0x00000000004adf43 in GraphMap::ProcessSequenceFileInParallel ()
#5 0x00002b292e7f096f in GOMP_parallel () from /share/apps/gcc/gcc530/lib64/libgomp.so.1
#6 0x00000000004b0b08 in GraphMap::ProcessSequenceFileInParallel(ProgramParameters*, SequenceFile*, long*, _IO_FILE*, long*, long*) ()
#7 0x00000000004b1796 in GraphMap::ProcessReadsFromSingleFile(ProgramParameters&, _IO_FILE*) ()
#8 0x00000000004b281e in GraphMap::Run(ProgramParameters&) ()
#9 0x00000000005087fe in main ()
But I got stuck again from here (short reminder: my goal is to find the full command that crushed the execution, the beginning of which is displayed on the first page of gdb like this:
Core was generated by `/tools/graphmap/bin/Linux-x64/graphmap align
--overlappe'.
Any help from here would be very appreciated.
Final Update, problem solved: I followed #ks1322 advice and went to this stack overflow thread and then I repeated what was described in the first answer and was able to get the arguments.
(short overview of what I understood with my limited knowledge of working with gdb: First you should check what threads were running the task, you can do it with "info threads" then you need to check which thread has "main" in it's stack, I did it by switching threads one by one with "thread #" and printing the stack with "info stack" until I found the thread that had main in it. in my case it was shown like this in the "info stack" #9 0x00000000005087fe in main ()". Then according to the instructions in the linked thread, I executed "set backtrace past-main" then "bt" and then changed frame to the frame containing "in _start ()" with the command "frame #". Almost done, now I ran the command "x/8gx $rsp+8" with showed few four lines with 2 addressees in each line. In my case the second line looked like this "0x7ffe38f872d8: 0x00007ffe38f88c35 0x00007ffe38f88c73" and now if everything was right this address can contain one of the arguments of the command that caused the crush, you can check it with "x/s" command like so: "x/s 0x00007ffe38f88c35" and it prints the argument. Important note: I had a lot of arguments so I needed to go to later addressees that did not show in the "x/8gx $rsp+8" command, I noticed that the addresses are incremented by constant value (3 in hex) so I kept manually in a calculator adding "3" to the address and checking the address with x/s until I got to my wanted argument)
Very messy solution and I hope someone could find an easier solution but that is all I could find.
Big thanks to #ks1322 who cleared up things for me and guided me to the solution.
You can load core dump with matching binary (the one for which core dump was generated) and print argv values in the frame where main function resides.
Something like this:
gdb /tools/graphmap/bin/Linux-x64/graphmap /4thExp/core.82912
Then go up in stack trace to initial frame where int main(int argc, char *argv[]) resides. Now you can print the number of arguments and their values from gdb prompt.
Update:
It appears that your binary is multithreaded and crash happened in some auxiliary thread. You should therefore find main thread and switch to it. Here is an example of how to do it for Firefox with many threads:
(gdb) t a a bt -1
Thread 59 (Thread 0x7f691deff700 (LWP 25924)):
#12 0x00007f69dce93f6f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
..........
..........
many threads are listed here
..........
..........
Thread 1 (Thread 0x7f69de01a740 (LWP 4143)):
#17 0x000056374cb38817 in main ()
(gdb) t 1
[Switching to thread 1 (Thread 0x7f69de01a740 (LWP 4143))]
#0 0x00007f69dce8800d in poll () at ../sysdeps/unix/syscall-template.S:84
84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Now gdb is switched to main thread (Thread 1).

Is it possible to obtain a backtrace inside a vDSO call?

I was trying to debug a deadlock issue in my code using gdb. When the program locked up, I attached to it with gdb to see what the threads were doing. For some reason, I cannot obtain backtraces for threads other than the current one:
(gdb) bt
#0 0xb774dcb0 in ?? ()
#1 0x8420e178 in TableCollect
#2 0x84200c12 in main
(gdb) thread apply all bt
Thread 3 (Thread 0xb6becb40 (LWP 18937)):
#0 0xb774dcb0 in ?? ()
#1 0x000d6ee6 in ?? ()
Thread 2 (Thread 0xb1f5eb40 (LWP 18939)):
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x5:
#0 0xb774dcb0 in ?? ()
Cannot access memory at address 0x5
(gdb) info threads
Id Target Id Frame
3 Thread 0xb6becb40 (LWP 18937) "loader.elf" 0xb774dcb0 in ?? ()
2 Thread 0xb1f5eb40 (LWP 18939) "Tuner" 0xb774dcb0 in ?? ()
* 1 Thread 0xb6bed700 (LWP 18936) "loader.elf" 0xb774dcb0 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 0xb1f5eb40 (LWP 18939))]
#0 0xb774dcb0 in ?? ()
(gdb) bt
Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x5:
#0 0xb774dcb0 in ?? ()
Cannot access memory at address 0x5
(gdb) thread 3
[Switching to thread 3 (Thread 0xb6becb40 (LWP 18937))]
#0 0xb774dcb0 in ?? ()
(gdb) bt
#0 0xb774dcb0 in ?? ()
#1 0x000d6ee6 in ?? ()
ninja#vm:build$ cat /proc/`pidof loader.elf`/maps | grep b774d
b774b000-b774d000 r--p 00000000 00:00 0 [vvar]
b774d000-b774f000 r-xp 00000000 00:00 0 [vdso]
So it looks like all threads are inside a system call? That's likely since I'm expecting them all to be stuck on ptread_mutex_lock, but why don't I have valid stack frames below that? Why the 0x5 address for thread 2? And why does thread 3 have 0xd6ee6 on the stack, which isn't even mentioned in the memory map?

track what function/code a thread is executing when debugging with gdb

Is it possible for me to track what function/code a thread is executing when debugging with gdb.I do the following
$gdb
$gdb attach pid
$info threads
27 Thread 0x7f0d3a0fe700 (LWP 3418) "BgHangManager" 0x00007f0d4fd9b0af in pthread_cond_wait##GLIBC_2.3.2 () from /lib64/libpthread.so.0
26 Thread 0x7f0d389ff700 (LWP 3419) "gdbus" 0x00007f0d4f098b3d in poll () from /lib64/libc.so.6
25 Thread 0x7f0d381fe700 (LWP 3420) "gmain" 0x00007f0d4f098b3d in poll () from /lib64/libc.so.6
24 Thread 0x7f0d36fff700 (LWP 3422) "Timer" 0x00007f0d4fd9b458 in pthread_cond_timedwait##GLIBC_2.3.2 () from /lib64/libpthread.so.0
23 Thread 0x7f0d3ee52700 (LWP 3423) "Cache2 I/O" 0x00007f0d4fd9b0af in pthread_cond_wait##GLIBC_2.3.2 () from /lib64/libpthread.so.0
$bt
Only gives me the stack-trace of the currently executing code while I would like to
for know what code is exuting in another thread for instance thread 26.
Worked around it by switching to the "wanted" thread and printing the stack-trace

Resources