0

我有工作的 C++ 守护进程。问题是守护程序每月崩溃一到两次。正如您从下面的 GDB 输出中看到的那样，当守护程序在容器中搜索unsigned intsessionID 时会发生这种情况。std::map <unsigned int const, SessionID*>我无法重现该问题，并认为它可能来自用户的数据有问题（可能std::sting cookie_ssid有一些意外数据，转换后strtoul出现问题。（知道，这不是正确的获取方式unsigned int）

.core守护进程崩溃后我只有文件。并在if (!_M_impl._M_key_compare(_S_key(__x), __k)). 任何想法如何解决这个问题？非常感谢。

GDB 输出：

#0  std::_Rb_tree<unsigned int, std::pair<unsigned int const, SessionID*>, std::_Select1st<std::pair<unsigned int const, SessionID*> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, SessionID*> > >::find (this=0x529df15c, __k=@0x7f5fab7c)
    at stl_tree.h:1376
##########
1376            if (!_M_impl._M_key_compare(_S_key(__x), __k))
##########
#0  std::_Rb_tree<unsigned int, std::pair<unsigned int const, SessionID*>, std::_Select1st<std::pair<unsigned int const, SessionID*> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, SessionID*> > >::find (
    this=0x529df15c, __k=@0x7f5fab7c) at stl_tree.h:1376
#1  0x0805e6be in TR::find_session (this=0x529df110,
    cookie_ssid=@0x47ef3614, ptr_to_ptr_session=0x7f5fac7c)
    at stl_map.h:542

函数TR::find_session发布如下：

bool TR::find_session ( const std::string &cookie_ssid, SessionID **ptr_to_ptr_session )
{
    unsigned int uint_sessionid = std::strtoul ( cookie_ssid.c_str(),NULL,0);

MUTEX_map_sessionids.lock_reading();
    std::map<unsigned int, SessionID*>::iterator it_sessionids = map_sessionids.find( uint_sessionid );

    if ( it_sessionids != map_sessionids.end() )
    { // exists
        *ptr_to_ptr_session = it_sessionids->second;
        MUTEX_map_sessionids.unlock();
        return true;
    }

MUTEX_map_sessionids.unlock();  
return false;   
}

编辑 我的清理功能，在分离线程（每分钟一次或 5 分钟）工作。根据评论的要求。我不确定这个功能。也许它的越野车......

void TR::cleanup_sessions () // not protected from multithread using! used only at one thread
{
std::list<SessionID*> list_to_clean; // tmplary store sessions to delete

MUTEX_map_sessionids.lock_reading();
std::map<unsigned int, SessionID*>::iterator it_sessionids = map_sessionids.begin();
MUTEX_map_sessionids.unlock();

while ( true )
{
    MUTEX_map_sessionids.lock_writing();
    if (it_sessionids == map_sessionids.end() )
    {
        MUTEX_map_sessionids.unlock();
        break;
    }

    SessionID *ptr_sessionid = it_sessionids->second;

    time_t secondsnow = time (NULL);

    ptr_sessionid->MUTEX_all_session.lock_reading();
    time_t lastaccesstime = ptr_sessionid->last_access_time;
    size_t total_showed = ptr_sessionid->map_showed.size(); 
    ptr_sessionid->MUTEX_all_session.unlock();


    if ( lastaccesstime and secondsnow - lastaccesstime > LOCALSESSION_LIFETIME_SEC ) // lifetime end!
    {
        // delete session from map
        map_sessionids.erase( it_sessionids++ ); // Increments the iterator but returns the original value for use by erase
        MUTEX_map_sessionids.unlock();              


        list_to_clean.push_back ( ptr_sessionid ); // at the end
    }
    else if ( total_showed == 0 and secondsnow - lastaccesstime > 36000 ) // not active for N secontes
    {
        map_sessionids.erase( it_sessionids++ ); // Increments the iterator but returns the original value for use by erase
        MUTEX_map_sessionids.unlock();

        // add pointer to list to delete it latter
        list_to_clean.push_back ( ptr_sessionid ); // at the end            
    }
    else
    {
        ++it_sessionids; // next
        MUTEX_map_sessionids.unlock();              
    }

}

// used? pause
if ( !list_to_clean.empty() ) 
{
    //sleep(1);
}

// cleanup session deleted from working map
while ( !list_to_clean.empty() )
{
    SessionID *ptr_sessionid_to_delete = list_to_clean.front();
    list_to_clean.pop_front();

    ptr_sessionid_to_delete->MUTEX_all_session.lock_writing(); // protected lock session mutex. can not delete session if its already locked. (additational protection)
    ptr_sessionid_to_delete->cleanup();
    delete ptr_sessionid_to_delete;
}

}

注意，正如您在每次迭代中看到的那样，我锁定/解锁 map_sessions，因为此时其他线程会查找/插入新会话及其关键，因为用户不能等待。

4

1 回答 1

2

请注意，对映射的任何修改都可能使该映射中的任何迭代器无效。你有：

MUTEX_map_sessionids.lock_reading();
std::map<unsigned int, SessionID*>::iterator it_sessionids = map_sessionids.begin();
MUTEX_map_sessionids.unlock();

现在，在此解锁之后，其他一些线程可能会立即获取锁并执行一些使 无效的操作it_sessionids，这将使其处于后续代码将破坏映射的状态，从而导致以后的崩溃。

您需要在迭代器的整个生命周期内获取并持有一个锁。看起来你有读/写锁，所以你只需要一直持有读锁，当你想修改地图时将其升级为写锁，然后在修改后立即将其降级为读锁。长时间持有读锁只会阻塞其他想获取写锁的线程，不会阻塞其他只需要读锁的线程。

在评论中回答您的问题：

  1. 如果你不能长时间持有锁，那么你就不能让迭代器在很长一段时间内保持有效。您可以做的一件事是偶尔记住您在地图中的大致位置，释放锁（给其他线程一个机会并使迭代器无效），然后重新获取锁并在大致相同的点创建一个新的迭代器。您可以在循环中间添加类似这样的内容：

    if (++count > limit) { // only do this every Nth iteration
    unsigned int now_at = it_sessionids->first;
    MUTEX_map_sessionids.unlock();
    // give others a chance
    MUTEX_map_sessionids.lock_reading();
    it_sessionids = map_sessionids.lower_bound(now_at);
    count = 0; }

  2. 将锁从只读升级为读/写是您的实现可能不支持的对读/写锁的原始操作。如果没有，那么你就不走运了，需要一直持有作家锁。

于 2012-12-06T19:58:44.913 回答