C++11 shared pointer thread safety is broken? - multithreading

As per C++ documentation, control block of the shared_ptr is thread-safe. ie, operator= or reset are accessible to multiple threads without explicit locking.
But I see a strange behavior; shared object is double freed occasionally:
#include <iostream>
#include <memory>
#include <unistd.h>
using namespace std;
class MyClass {
public:
MyClass(string x) : name(x) {cout<<"C->"<<name<<endl;};
~MyClass() {cerr<<"D->"<<name<<endl;};
string name;
};
shared_ptr<MyClass> a;
void* tfunc(void*) {
while(1){
{
shared_ptr<MyClass> s = a;
usleep(5);
}
}
}
int main(void) {
pthread_t threadid;
a = make_shared<MyClass>("a");
if(pthread_create(&threadid, NULL, tfunc, NULL)) {
cout<<"pthread_create error"<<endl;
return -1;
}
while(1){
usleep(5);
a = make_shared<MyClass>("b");
}
pthread_join(threadid, NULL);
return 0;
}
Here is the Address Sanitizer output:
==28588==ERROR: AddressSanitizer: heap-use-after-free on address 0xb33a7ad4 at pc 0x080490c4 bp 0xb54ff1d8 sp 0xb54ff1c8
WRITE of size 4 at 0xb33a7ad4 thread T1
#0 0x80490c3 in __exchange_and_add /usr/include/c++/6/ext/atomicity.h:49
#1 0x80491ed in __exchange_and_add_dispatch /usr/include/c++/6/ext/atomicity.h:82
#2 0x8049a9e in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/6/bits/shared_ptr_base.h:147
#3 0x80498a3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/6/bits/shared_ptr_base.h:662
#4 0x804977e in std::__shared_ptr<MyClass, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/6/bits/shared_ptr_base.h:928
#5 0x8049797 in std::shared_ptr<MyClass>::~shared_ptr() /usr/include/c++/6/bits/shared_ptr.h:93
#6 0x80492d7 in tfunc(void*) /tmp/main.cpp:19
#7 0xb7248c4e (/usr/lib/i386-linux-gnu/libasan.so.3+0x26c4e)
#8 0xb6ea5304 in start_thread (/lib/i386-linux-gnu/libpthread.so.0+0x6304)
#9 0xb6fb347d in __clone (/lib/i386-linux-gnu/libc.so.6+0xe947d)
0xb33a7ad4 is located 4 bytes inside of 36-byte region [0xb33a7ad0,0xb33a7af4)
freed by thread T0 here:
#0 0xb72e7174 in operator delete(void*) (/usr/lib/i386-linux-gnu/libasan.so.3+0xc5174)
#1 0x804ace0 in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2> >::deallocate(std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2>*, unsigned int) /usr/include/c++/6/ext/new_allocator.h:110
#2 0x804ab07 in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2> > >::deallocate(std::allocator<std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2> >&, std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2>*, unsigned int) /usr/include/c++/6/bits/alloc_traits.h:442
#3 0x804a818 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr() /usr/include/c++/6/bits/allocated_ptr.h:73
#4 0x804b0aa in std::_Sp_counted_ptr_inplace<MyClass, std::allocator<MyClass>, (__gnu_cxx::_Lock_policy)2>::_M_destroy() /usr/include/c++/6/bits/shared_ptr_base.h:537
#5 0x8049bbe in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/include/c++/6/bits/shared_ptr_base.h:166
#6 0x80498a3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/include/c++/6/bits/shared_ptr_base.h:662
#7 0x804977e in std::__shared_ptr<MyClass, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/include/c++/6/bits/shared_ptr_base.h:928
#8 0x8049cd4 in std::__shared_ptr<MyClass, (__gnu_cxx::_Lock_policy)2>::operator=(std::__shared_ptr<MyClass, (__gnu_cxx::_Lock_policy)2>&&) /usr/include/c++/6/bits/shared_ptr_base.h:1003
#9 0x8049a7c in std::shared_ptr<MyClass>::operator=(std::shared_ptr<MyClass>&&) /usr/include/c++/6/bits/shared_ptr.h:294
#10 0x8049430 in main /tmp/main.cpp:35
#11 0xb6ee2275 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18275)
GCC-6.2 and LLVM-3.9 show same behavior. Is it a bug in the C++ library?

No. = and reset are not thread safe. The shared_ptr overloads of std::atomic_... functions are needed.
"Control block is thread-safe" means you can use = and reset in multiple threads (but each thread uses a separate shared_ptr), even if all shared_ptr objects are copies of each other.

Related

why is library loaded via LD_PRELOAD operating before initialization?

In the following minimal example, a library loaded via LD_PRELOAD with functions to intercept fopen and openat is apparently operating before its initialization. (Linux is CentOS 7.3). Why??
library file comm.c:
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdarg.h>
#include <stdio.h>
#include <fcntl.h>
typedef FILE *(*fopen_type)(const char *, const char *);
// initialize to invalid value (non-NULL)
// init() should initialize this correctly
fopen_type g_orig_fopen = (fopen_type) 1;
typedef int (*openat_type)(int, const char *, int, ...);
openat_type g_orig_openat;
void init() {
g_orig_fopen = (fopen_type)dlsym(RTLD_NEXT,"fopen");
g_orig_openat = (openat_type)dlsym(RTLD_NEXT,"openat");
}
FILE *fopen(const char *filename, const char *mode) {
// have to do this here because init is not called yet???
FILE * const ret = ((fopen_type)dlsym(RTLD_NEXT,"fopen"))(filename, mode);
printf("g_orig_fopen %p fopen file %s\n", g_orig_fopen, filename);
return ret;
}
int openat(int dirfd, const char* pathname, int flags, ...) {
int fd;
va_list ap;
printf("g_orig_fopen %p openat file %s\n", g_orig_fopen, pathname);
if (flags & (O_CREAT)) {
va_start(ap, flags);
fd = g_orig_openat(dirfd, pathname, flags, va_arg(ap, mode_t));
}
else
fd = g_orig_openat(dirfd, pathname, flags);
return fd;
}
compiled with:
gcc -shared -fPIC -Wl,-init,init -ldl comm.c -o comm.so
I have an empty subdirectory subdir. Then it appears the library function fopen is called before init:
#LD_PRELOAD=./comm.so find subdir
g_orig_fopen 0x1 fopen file /proc/filesystems
g_orig_fopen 0x1 fopen file /proc/mounts
subdir
g_orig_fopen 0x7f7b2e574620 openat file subdir
Obviously, fopen is called before initialization of comm.so. It is interesting to place a breakpoint in fopen() in order to understand (check this link in order to get debug symbols of various packages). I get this backtrace:
(gdb) bt
#0 fopen (filename=0x7ffff79cd2e7 "/proc/filesystems", mode=0x7ffff79cd159 "r") at comm.c:28
#1 0x00007ffff79bdb0e in selinuxfs_exists_internal () at init.c:64
#2 0x00007ffff79b5d98 in init_selinuxmnt () at init.c:99
#3 init_lib () at init.c:154
#4 0x00007ffff7de88aa in call_init (l=<optimized out>, argc=argc#entry=1, argv=argv#entry=0x7fffffffdf58, env=env#entry=0x7fffffffdf68) at dl-init.c:72
#5 0x00007ffff7de89bb in call_init (env=0x7fffffffdf68, argv=0x7fffffffdf58, argc=1, l=<optimized out>) at dl-init.c:30
#6 _dl_init (main_map=0x7ffff7ffe170, argc=1, argv=0x7fffffffdf58, env=0x7fffffffdf68) at dl-init.c:120
#7 0x00007ffff7dd9c5a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8 0x0000000000000001 in ?? ()
#9 0x00007fffffffe337 in ?? ()
#10 0x0000000000000000 in ?? ()
It is obvious, comm.so depends on other libraries (libdl.so that requires libselinux.so). And comm.so is not the only library that declare an init function. libdl.so and libselinux.so also declare ones.
So, comm.so is the first library to be loaded (because it is declared with LD_PRELOAD) but, comm.so depends on libdl.so (because of -ldl during compilation) and libdl.so depends on libselinux.so. So, in order to load comm.so, init functions from libdl.so and libselinux.so are called before. And finally, init function from libselinux.so call fopen()
Personally, I usually resolve dynamic symbols during first call to the symbol. Like this:
FILE *fopen(const char *filename, const char *mode) {
static FILE *(*real_fopen)(const char *filename, const char *mode) = NULL;
if (!real_fopen)
real_fopen = dlsym(RTLD_NEXT, "fopen");
return real_fopen(filename, mode);
}

Installing a new route in linux routing table using rtnetlink socket

I have written a user space program that should install a new route in routing table. What i am noticing is , no if bytes sendmsg fn returns is correct, yet program is failing to install a new route. When i try to diagnose a problem using gdb on linux kernel, i find that garbage data is being sent from user space to kernel netlink socket.
output
[root#localhost rtnetlink]# ./netlink_add_route.exe
bytes send = 52
Sharing code:
typedef struct _request
{
struct nlmsghdr netlink_header;
struct rtmsg rt_message;
char buffer[1024];
} req_t;
int addattr_l(struct nlmsghdr *n, int maxlen, int type, void *data, int alen)
{
/* alen is the length of the data. Add sizeof(struct rtattr) to it to accomodate
type, length, value format for rtattr */
int len = RTA_LENGTH(alen); // (RTA_ALIGN(sizeof(struct rtattr)) + (len))
struct rtattr *rta;
/* size of request should not be violated*/
if (NLMSG_ALIGN(n->nlmsg_len) + len > maxlen)
return -1;
/* go to end of buffer in request data structure*/
rta = (struct rtattr*)(((char*)n) + NLMSG_ALIGN(n->nlmsg_len));
/* specify attribute using TLV format*/
rta->rta_type = type;
rta->rta_len = len;
memcpy(RTA_DATA(rta), data, alen);
/* increase the nlmsg_len to accomodate the added new attribute*/
n->nlmsg_len = NLMSG_ALIGN(n->nlmsg_len) + len;
return 0;
}
static void
initialisation(){
/* initialise the request structure*/
int index = 3,
gw = 3232236545/*192.168.4.1*/,
dst = 3232235776/*192.168.1.0*/;
memset(&request, 0, sizeof(request));
/* set the nlmsg_len = nl header + underlying structure*/
request.netlink_header.nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg)); /*NLMSG_HDRLEN + sizeof(struct rtmsg);*/
/* set the flags that facilitates adding a route in routing table*/
request.netlink_header.nlmsg_flags = NLM_F_REQUEST|NLM_F_CREATE;
/* note that inet_rtm_newroute() is the fn in kernel which will be eventually called to add a new route in routing table*/
request.netlink_header.nlmsg_type = RTM_NEWROUTE;
/* Now filling the rtmsg*/
request.rt_message.rtm_family = AF_INET;
request.rt_message.rtm_table = RT_TABLE_MAIN;
request.rt_message.rtm_protocol = RTPROT_BOOT;/*Route installed during boot*/
request.rt_message.rtm_scope = RT_SCOPE_UNIVERSE;
request.rt_message.rtm_type = RTN_UNICAST; /*Gateway or direct route */
/* Add routing info*/
addattr_l(&request.netlink_header, sizeof(request), RTA_GATEWAY, &gw, sizeof(gw));
addattr_l(&request.netlink_header, sizeof(request), RTA_DST, &dst, sizeof(dst));
addattr_l(&request.netlink_header, sizeof(request), RTA_OIF, &index, sizeof(index));
/* For adding a route, the gateway, destination address and the interface
will suffice, now the netlink packet is all set to go to the kernel*/
}
static void
send_request(int fd){
int rc = 0;
struct msghdr msg;
struct sockaddr_nl nladdr;
struct iovec iov;
iov.iov_base = (void*)&request.netlink_header;
iov.iov_len = request.netlink_header.nlmsg_len ;/* Total length : from request start to end of last attribute*/
memset(&nladdr, 0, sizeof(nladdr));
nladdr.nl_family = AF_NETLINK;
nladdr.nl_pid = 0; /* For Linux Kernel */
nladdr.nl_groups = 0;
msg.msg_name = (void *)&nladdr;
msg.msg_namelen = sizeof(nladdr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
rc = sendmsg(fd, &msg, 0);
printf("bytes send = %d\n", rc);
}
int
main(int argc, char *argv[])
{
struct sockaddr_nl la;
int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
if(fd < 0){
printf("socket creation failed\n");
return -1;
}
bzero(&la, sizeof(la));
la.nl_family = AF_NETLINK;
la.nl_pid = getpid();
la.nl_groups = 0;
if(bind(fd, (struct sockaddr*) &la, sizeof(la)) < 0){
printf("Bind failed\n");
return -1;
}
initialisation();
send_request(fd);
close(fd);
}
gdb output
Breakpoint 1, inet_rtm_newroute (skb=0xbb53f20, nlh=0xb96ed00) at net/ipv4/fib_frontend.c:732
732 {
(gdb) bt
#0 inet_rtm_newroute (skb=0xbb53f20, nlh=0xb96ed00) at net/ipv4/fib_frontend.c:732
#1 0x081f1b28 in rtnetlink_rcv_msg (skb=0xbb53f20, nlh=0xb96ed00) at net/core/rtnetlink.c:3412
#2 0x081fcd07 in netlink_rcv_skb (skb=0xbb53f20, cb=0x81f19de <rtnetlink_rcv_msg>)
at net/netlink/af_netlink.c:3017
#3 0x081efcb9 in rtnetlink_rcv (skb=0xbb53f20) at net/core/rtnetlink.c:3418
#4 0x081fc7e4 in netlink_unicast_kernel (ssk=<optimized out>, skb=<optimized out>, sk=<optimized out>) at net/netlink/af_netlink.c:1834
#5 netlink_unicast (ssk=0xbb03000, skb=0xbb53f20, portid=0, nonblock=0) at net/netlink/af_netlink.c:1860
#6 0x081fcbf3 in netlink_sendmsg (sock=0xa50a700, msg=0xbb71e3c, len=52) at net/netlink/af_netlink.c:2511
#7 0x081cf181 in sock_sendmsg_nosec (msg=<optimized out>, sock=<optimized out>) at net/socket.c:611
#8 sock_sendmsg (sock=0xa50a700, msg=<optimized out>) at net/socket.c:621
#9 0x081cf781 in ___sys_sendmsg (sock=0xa50a700, msg=<optimized out>, msg_sys=0xbb71e3c, flags=0,
used_address=0x0) at net/socket.c:1947
#10 0x081d044f in __sys_sendmsg (fd=3, msg=0xbfd5cc40, flags=0) at net/socket.c:1981
#11 0x081d0a97 in SYSC_sendmsg (flags=<optimized out>, msg=<optimized out>, fd=<optimized out>)
at net/socket.c:1992
#12 SyS_sendmsg (flags=0, msg=-1076507584, fd=3) at net/socket.c:1988
#13 SYSC_socketcall (args=<optimized out>, call=<optimized out>) at net/socket.c:2397
#14 SyS_socketcall (call=16, args=-1076507632) at net/socket.c:2315
#15 0x0805ba59 in handle_syscall (r=0xbbab3f0) at arch/um/kernel/skas/syscall.c:37
#16 0x08069147 in handle_trap (local_using_sysemu=<optimized out>, regs=<optimized out>,
pid=<optimized out>) at arch/um/os-Linux/skas/process.c:172
#17 userspace (regs=0xbbab3f0) at arch/um/os-Linux/skas/process.c:384
#18 0x080594df in fork_handler () at arch/um/kernel/process.c:154
#19 0x00000000 in ?? ()
(gdb) f 6
#6 0x081fcbf3 in netlink_sendmsg (sock=0xa50a700, msg=0xbb71e3c, len=52) at net/netlink/af_netlink.c:2511
2511 err = netlink_unicast(sk, skb, dst_portid, msg->msg_flags&MSG_DONTWAIT);
(gdb) p msg
$1 = (struct msghdr *) 0xbb71e3c
(gdb) p *(struct msghdr *) 0xbb71e3c
$2 = {msg_name = 0xbb71d98, msg_namelen = 12, msg_iter = {type = 1, iov_offset = 0, count = 0, {
iov = 0xbb71d60, kvec = 0xbb71d60, bvec = 0xbb71d60}, nr_segs = 0}, msg_control = 0x4,
msg_controllen = 0, msg_flags = 0, msg_iocb = 0x0}
(gdb) f 10
#10 0x081d044f in __sys_sendmsg (fd=3, msg=0xbfd5cc40, flags=0) at net/socket.c:1981
1981 err = ___sys_sendmsg(sock, msg, &msg_sys, flags, NULL);
(gdb) p msg
$3 = (struct user_msghdr *) 0xbfd5cc40
(gdb) p *(struct user_msghdr *) 0xbfd5cc40
Cannot access memory at address 0xbfd5cc40
As you can see above, the msg recieved in kernel is not accessible. When i apply the gdb on sendmsg fn in application and expand the msg being sent to kernel, i find everything perfect. What is causing this msg corruption in between user space and kernel ? Can anyone pls help diagnose the issue ?
I am using kernel version 4.5.3.
sharing the link to src file if someone wants to run the program.
https://drive.google.com/file/d/0B56H_R1fVFZXRjNWRkZ3M09pY2s/view?usp=sharing
Thanks.
I could successfully make it work. The issue is the way RTA_DST and RTA_GATEWAY is added. You need to use inet_prefix for dst.
Please note dst.data[],dst.bytelen and dst.bitlen are all just some random values. Please initialize as required for your solution. (this is just to demonstrate that it works!)
typedef struct
{
__u16 flags;
__u16 bytelen;
__s16 bitlen;
__u16 family;
__u32 data[8];
} inet_prefix;
inet_prefix dst;
dst.data[0] = 11;
dst.data[1] = 12;
dst.data[2] = 13;
dst.data[3] = 14;
dst.data[4] = 15;
dst.data[5] = 16;
dst.data[6] = 17;
dst.data[7] = 17;
dst.bytelen = 32;
dst.bitlen = dst.bytelen * 8;
/* mask */
request.rt_message.rtm_dst_len = 24;
//addattr_l(&request.netlink_header, sizeof(request), RTA_GATEWAY, &gw, sizeof(gw));
addattr_l(&request.netlink_header, sizeof(request), RTA_DST, &dst, sizeof(dst));
As a sample I added 'dst' entry and commented out 'gw' entry.
For 'gw' too you have to follow similar struct inet_prefix.
Entry created:
12.0.32.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

when pthread_once encounters reentrancy

What would happen in the situation below?
#include <pthread.h>
#include <stdio.h>
static pthread_once_t random_is_initialized = PTHREAD_ONCE_INIT;
void initialize(){
foo("init()");
}
int foo(char *str)
{
pthread_once(&random_is_initialized, initialize);
printf("%s", str);
}
int main(){
foo("main");
}
Will it cause infinite recursion? Thanks!
[edit] I ran the code. It seems the code does not cause infinite recursion, but it blocks at the second pthread_once that I have to "ctrl + c". That is, deadlock happened.
(gdb) bt
#0 0x0012d422 in __kernel_vsyscall ()
#1 0x00139404 in pthread_once () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x080484a3 in foo (str=0x8048590 "init()") at main.c:12
#3 0x08048486 in initialize () at main.c:6
#4 0x00139430 in pthread_once () from /lib/tls/i686/cmov/libpthread.so.0
#5 0x080484a3 in foo (str=0x804859a "main") at main.c:12
#6 0x080484ce in main () at main.c:17
On a proper pthread implementation init_routine() will only be called once so there will be no infinite recursion. However, all other callers to pthread_once() must wait until init_routine() has finished executing. In this case it will never finish so you've created a deadlock.

Assertion on mutex when using multiple threads and mutexes

As a part of a project I'm writing a logger function. This logger function sends an e-mail when the program wants to log something. Since it has happened that the SMTP server was non responsive, I've decided to do the sending of the mails in a separate thread.
This thread reads messages from an std::deque which is filled by the logging function.
The thread is setup as follows:
while (!boost::this_thread::interruption_requested())
{
EmailItem emailItem;
{
boost::unique_lock<boost::mutex> lock(mMutex);
while (mEmailBuffer.empty())
mCond.wait(lock);
bufferOverflow = mBufferOverflow;
mBufferOverflow = false;
nrOfItems = mEmailBuffer.size();
if (nrOfItems > 0)
{
emailItem = mEmailBuffer.front();
mEmailBuffer.pop_front();
}
}
if (nrOfItems > 0)
{
bool sent = false;
while(!sent)
{
try
{
..... Do something with the message .....
{
boost::this_thread::disable_interruption di;
boost::lock_guard<boost::mutex> lock(mLoggerMutex);
mLogFile << emailItem.mMessage << std::endl;
}
sent = true;
}
catch (const std::exception &e)
{
// Unable to send mail, an exception occurred. Retry sending it after some time
sent = false;
boost::this_thread::sleep(boost::posix_time::seconds(LOG_WAITBEFORE_RETRY));
}
}
}
}
The function log() adds a new message to the deque (mEmailBuffer) as follows:
{
boost::lock_guard<boost::mutex> lock(mMutex);
mEmailBuffer.push_back(e);
mCond.notify_one();
}
When the main program exits, the destructor of the logger object is called. This is where it goes wrong, the application crashes with an error:
/usr/include/boost/thread/pthread/mutex.hpp:45: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.
The destructor merely calls an interrupt on the thread and then joins it:
mQueueThread.interrupt();
mQueueThread.join();
In the main program, I use multiple different classes which make use of boost threading and mutex as well, could this cause this behaviour? Not calling the destructor of the logger object results in no errors, as does using the logger object and not doing anything else.
My guess is I am doing something very wrong, or there is a bug in the threading library when using multiple threads divided over several classes.
Does anyone have a idea what the reason for this error might be?
EDIT:
I did as #Andy T proposed and stripped the code as much as possible. I removed nearly everything in the function which is ran in a different thread. The thread now looks like:
void Vi::Logger::ThreadedQueue()
{
bool bufferOverflow = false;
time_t last_overflow = 0;
unsigned int nrOfItems = 0;
while (!boost::this_thread::interruption_requested())
{
EmailItem emailItem;
// Check for new log entries
{
boost::unique_lock<boost::mutex> lock(mMutex);
while (mEmailBuffer.empty())
mCond.wait(lock);
}
}
}
The problem still persists. Backtracking of the problem however showed me something different from the initial code:
#0 0x00007ffff53e9ba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff53ed6b0 in abort () at abort.c:92
#2 0x00007ffff53e2a71 in __assert_fail (assertion=0x7ffff7bb6407 "!pthread_mutex_lock(&m)", file=<value optimized out>, line=50, function=0x7ffff7bb7130 "void boost::mutex::lock()") at assert.c:81
#3 0x00007ffff7b930f3 in boost::mutex::lock (this=0x7fffe2c1b0b8) at /usr/include/boost/thread/pthread/mutex.hpp:50
#4 0x00007ffff7b9596c in boost::unique_lock<boost::mutex>::lock (this=0x7fffe48b3b40) at /usr/include/boost/thread/locks.hpp:349
#5 0x00007ffff7b958db in boost::unique_lock<boost::mutex>::unique_lock (this=0x7fffe48b3b40, m_=...) at /usr/include/boost/thread/locks.hpp:227
#6 0x00007ffff6ac2bb7 in Vi::Logger::ThreadedQueue (this=0x7fffe2c1ade0) at /data/repos_ViNotion/stdcomp/Logging/trunk/src/Logger.cpp:198
#7 0x00007ffff6acf2b2 in boost::_mfi::mf0<void, Vi::Logger>::operator() (this=0x7fffe2c1d890, p=0x7fffe2c1ade0) at /usr/include/boost/bind/mem_fn_template.hpp:49
#8 0x00007ffff6acf222 in boost::_bi::list1<boost::_bi::value<Vi::Logger*> >::operator()<boost::_mfi::mf0<void, Vi::Logger>, boost::_bi::list0> (this=0x7fffe2c1d8a0, f=..., a=...) at /usr/include/boost/bind/bind.hpp:253
#9 0x00007ffff6acf1bd in boost::_bi::bind_t<void, boost::_mfi::mf0<void, Vi::Logger>, boost::_bi::list1<boost::_bi::value<Vi::Logger*> > >::operator() (this=0x7fffe2c1d890) at /usr/include/boost/bind/bind_template.hpp:20
#10 0x00007ffff6aceff2 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, Vi::Logger>, boost::_bi::list1<boost::_bi::value<Vi::Logger*> > > >::run (this=0x7fffe2c1d760)
at /usr/include/boost/thread/detail/thread.hpp:56
#11 0x00007ffff2cc5230 in thread_proxy () from /usr/lib/libboost_thread.so.1.42.0
#12 0x00007ffff4d87971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#13 0x00007ffff549c92d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x0000000000000000 in ?? ()
Might it be possible that mMutex is not unlocked in the combination of using an unique_lock() and then interrupting the thread?
do you join your thread before exiting? as tyz suggested, your thread can still keep it locked when mutex is destroyed.
[EDIT]
you didn't provide complete example that can be compiled and run, it's hard to help w/o it.
check this simple example that should be similar to your one:
#include <boost/thread.hpp>
#include <boost/bind.hpp>
#include <queue>
class Test
{
public:
Test()
{
thread = boost::thread(boost::bind(&Test::thread_func, this));
}
~Test()
{
thread.interrupt();
thread.join();
}
void run()
{
for (size_t i = 0; i != 10000; ++i) {
boost::lock_guard<boost::mutex> lock(mutex);
queue.push(i);
condition_var.notify_one();
}
}
private:
void thread_func()
{
while (!boost::this_thread::interruption_requested())
{
{
boost::unique_lock<boost::mutex> lock(mutex);
while (queue.empty())
condition_var.wait(lock);
queue.pop();
}
}
}
private:
boost::thread thread;
boost::mutex mutex;
boost::condition_variable condition_var;
std::queue<int> queue;
};
int main()
{
Test test;
test.run();
return 0;
}
compare with your case
You should unlock mutex before you delete it.

Backtracing on Linux 64 bit from Signal Handler with malloc/free on callstack

Below is an example of source I want to use on a machine running "Red Hat Enterprise Linux 5.5 (Tikanga) Kernel 2.6.18-194.el5xen x86_64" OS.
The general idea is that I want to have backtrace of some thread, so I am raising a SIGUSR1 signal for that thread and a handler does a backtrace() call.
In my scenario as below, FrameTwo function calls malloc and free in a loop. Whenever the signal is raised for this particular thread and free or malloc is on the callstack, the progream crashes when the signal handler calls backtrace().
(gdb) where (stack from gdb)
0 0x0000003e67207638 in ?? ()
1 0x0000003e672088bb in _Unwind_Backtrace
2 0x00000037ba0e5fa8 in backtrace ()
3 0x000000000040071a in handler ()
4 <signal handler called>
5 0x00000037ba071fac in _int_free ()
6 0x0000000a33605000 in ?? ()
7 0x000000004123b130 in ?? ()
8 0x00000000004007d4 in ThreadFunction ()
9 0x000000001f039020 in ?? ()
10 0x000000004123b940 in ?? ()
11 0x0000000000000001 in ?? ()
12 0x0000000000000000 in ?? ()
I learned from other sources that backtrace shouldn't be called from a signal handler, so I have written my own function grok_and_print_thread_stack() for this case.
It uses the RBP register to navigate the stack (RBP contains the base pointer of the current frame points to the previous frame's base pointer), but this algorithm does not work in this case either: when _int_free () is on the callstack, the RBP register navigation algorithm breaks, because the RBP of _int_free is some value like 0x20 which is not a valid frame's base pointer.
Does anyone know how a callstack can be navigated from the registers? Or how can I use backtrace for my purpose?
#include "stdio.h"
#include "stdlib.h"
#include "pthread.h"
#include "signal.h"
#include "syscall.h"
#include "string.h"
#include "inttypes.h"
//####################################################################
//gcc BacktraceTestProgram.c -o backtracetest -lpthread
//./backtracetest
//gdb -c core backtracetest
//####################################################################
volatile sig_atomic_t flag = 1;
int thlist[6] = {0};
int cnt = 0;
int *memory = NULL;
//####################################################################
void raiseUserSignal(int tid)
{
union sigval value;
value.sival_int = 1;
sigqueue(tid,SIGUSR1, value);
}
//####################################################################
int grok_and_print_thread_stack()
{
int ret = 0;
register uint64_t* rbp asm("rbp");
/*if buffer was built before, add separator */
uint64_t *previous_bp;
/*save pointers*/
previous_bp = rbp;
/* stack Traversal */
while(previous_bp)
{
uint64_t *next_bp;
next_bp = (uint64_t*)*previous_bp;
printf("Read BP: %lx \n", next_bp);
if ( NULL == (void*)next_bp )
{
printf("Reached the top of the stack\n");
fflush(stdout);
break;
}
previous_bp = next_bp;
}
return ret;
}
//####################################################################
void handler(int signum, siginfo_t *info, void *context)
{
int nptrs = 0 ;
void *buffer[100] = {NULL};
char **strings = NULL;
nptrs = backtrace(buffer, 100);
flag = 1;
}
//####################################################################
void FrameTwo(const char A)
{
do{
if( memory == NULL)
memory = (int *)malloc(sizeof(int) *5);
if(memory != NULL) {
free(memory);
memory = NULL;
}
}while(1);
}
//####################################################################
void FrameOne(int no)
{
FrameTwo('A');
}
//####################################################################
void *ThreadFunction( void *ptr )
{
int tid = syscall(SYS_gettid);
thlist[cnt++] = tid;
FrameOne(10);
}
//####################################################################
void RegisterSignalHandler()
{
/* Register a Signal Handler */
struct sigaction usrsig_action;
usrsig_action.sa_flags = SA_SIGINFO;
usrsig_action.sa_sigaction = &handler;
sigaction (SIGUSR1, &usrsig_action, NULL);
}
//####################################################################
int main(int no , char *argc[] )
{
int iret1;
pthread_t thread1;
RegisterSignalHandler();
/* Create independent threads each of which will execute function */
iret1 = pthread_create( &thread1, NULL, ThreadFunction, NULL);
while(cnt == 0);
while(1) {
if(flag == 1){
flag = 0;
raiseUserSignal(thlist[0]);
}
}
pthread_join( thread1, NULL);
return 0;
}
In general x86_64 programs are likely to have been built with -fomit-frame-pointer as it is the default when optimisation is on.
What that means is that RBP is not usable for unwinding the stack and you will either need to use the DWARF unwind information (if you have debugging information available) or the exception unwind table.
You may want to look at the libunwind project.
The primary goal of [libunwind] is to define a portable and efficient C programming interface (API) to determine the call-chain of a program. [...] As such, the API is useful in a number of applications. Some examples include:
debuggers
The libunwind API makes it trivial for debuggers to generate the call-chain (backtrace) of the threads in a running program/
In particular, have a look at the local unwinding section of their documentation, it contains explanations and the following code example (with you need to link with -lunwind) that prints the backtrace of the current function:
#define UNW_LOCAL_ONLY
#include <libunwind.h>
void show_backtrace (void) {
unw_cursor_t cursor; unw_context_t uc;
unw_word_t ip, sp;
unw_getcontext(&uc);
unw_init_local(&cursor, &uc);
while (unw_step(&cursor) > 0) {
unw_get_reg(&cursor, UNW_REG_IP, &ip);
unw_get_reg(&cursor, UNW_REG_SP, &sp);
printf ("ip = %lx, sp = %lx\n", (long) ip, (long) sp);
}
}

Resources