Crash while inserting int a set - c++

Question

My program seems to be crashing while inserting and int into a set, and I cannot track down the reason for this. Here is there relevant code:
bool request::check_list(std::vector<int> search_vec)
{
std::set<int> *tmp_ptr = create_int_set();
boost::shared_ptr<std::set<int> > c_list(tmp_ptr);
if(aerospike_query_foreach(as, &err, NULL, &query, process_set, &c_list) != AEROSPIKE_OK)
{
return false;
}
for(int i = 0; i < search_vec.size(); i++)
{
if(c_list->find(search_vec[i]) != c_list->end())
{
c_list_value_ = search_vec[i];
return true;
}
}
return false;
}
bool request::process_set(const as_val *val, void * udata)
{
try
{
boost::shared_ptr<std::set<int> > c_set = *(boost::shared_ptr<std::set<int> > *)(udata);
if(val == NULL)
{
return true;
}
if(val->type == AS_REC)
{
if (val!=NULL)
{
as_record *rec = as_record_fromval(val);
if (rec!=NULL)
{
as_integer* c_id = as_record_get_integer(rec,"c_id");
int cid = 0;
cid = boost::lexical_cast<int>(c_id->value);
if(c_set != nullptr)
{
c_set->insert(c_id);
}
as_record_destroy(rec);
as_integer_destroy(c_id);
}
}
return true;
}catch(...){}
return false;
}
The line c_set->insert(c_id); is causing a segfault. Here is this backtrace of the crash:
#0 0x00007f2064299f94 in std::_Rb_tree_rotate_right(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*&) () from /usr/lib64/libstdc++.so.6
#1 0x00007f206429a12b in std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib64/libstdc++.so.6
#2 0x00000000004829d9 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_<int const&> (this=0x7f1fcc005440, __x=0x0, __p=0x7f1f3c0009a0, __v=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tree.h:981
#3 0x000000000047f1e0 in std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, std::allocator<int> >::_M_insert_unique<int const&> (this=0x7f1fcc005440, __v=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tree.h:1299
#4 0x000000000047c473 in std::set<int, std::less<int>, std::allocator<int> >::insert (this=0x7f1fcc005440, __x=#0x7f20159e729c)
at /opt/centos/devtoolset-1.1/root/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_set.h:415
#5 0x00000000004765ee in request::process_set (val=0x7f20159e73e0, udata=0x7f200b9d6620) at ../../request.cpp:1862
I am assuming there is a problem where the set is not being initialized, or something similar to that. Here is how I create and pass the set from the another function, I have tried two ways to create it:
boost::shared_ptr<std::set<int> > c_list(new std::set<int>());
and
std::set<int> *tmp_ptr = create_int_set();
boost::shared_ptr<std::set<int> > c_list(tmp_ptr);
std::set<int>* request::create_int_set()
{
return new std::set<int>();
}
The calling function is a callback function from a database driver, that takes in a few different objects, most notably however are the process_set and the c_list, which is passed as a void*:
aerospike_query_foreach(as, &err, NULL, &query, process_set, &c_list)
This crash does not happen all the time, in fact it is fairly rare, which makes me think there is something I am doing wrong, some sort of undefined behavior. Any help would be greatly appreciated!

Answer 1

The aerospike APi documentation says for the callback (i.e. process_set(), here):
Execute a query and call the callback function for each result item.
Multiple threads will likely be calling the callback in parallel.
Therefore, your callback implementation should be thread safe.
As several threads might insert at the same time in the same set (the one pointed to by your shared pointer), you'll get race conditions and hence undefined behaviour !
So I think that you should protect at least your set insertion block with a lock_guard on a mutex.
Important edit: boost::shared_ptr<> can't assumed to be thread safe. In the examples on boost.org, they suggest that a shared pointer going out of scope might cause a race. It may therefore be highly advisable to follow Matthew Moss's suggestion in the comments and use a raw pointer to the set within the bounds of process_set().