1
我正在使用boost :: shared_ptr來處理我的類指針。 而在我的班級中，有一個std:set<boost::uuids::uuid>類型的成員。 我只在初始代碼中設置此成員值一次。我有雙重檢查沒有緩衝區溢出。 我已經運行valgrind來檢查，並且沒有內存錯誤報告。在std :: set <boost :: uuids :: uuid>的析構函數中，我在_int_free中遇到了段錯誤（core dump）。爲什麼？
但是，在我的類析構函數中，我在_int_free中獲得了一個核心轉儲。這是它的調用堆棧：
(gdb) bt
#0 0x0098c02e in _int_free() from /lib/libc.so.6
#1 0x048ec552 in operator delete(void*)() from /usr/lib/libstdc++.so.6
#2 0x08056372 in std::_Rb_tree<boost::uuids::uuid, boost::uuids::uuid, std::_Identity<boost::uuids::uuid>, std::less<boost::uuids::uuid>, std::allocator<boost::uuids::uuid> >::_M_erase(std::_Rb_tree_node<boost::uuids::uuid>*)()
#3 0x08056367 in std::_Rb_tree<boost::uuids::uuid, boost::uuids::uuid, std::_Identity<boost::uuids::uuid>, std::less<boost::uuids::uuid>, std::allocator<boost::uuids::uuid> >::_M_erase(std::_Rb_tree_node<boost::uuids::uuid>*)()
#4 0x08056367 in std::_Rb_tree<boost::uuids::uuid, boost::uuids::uuid, std::_Identity<boost::uuids::uuid>, std::less<boost::uuids::uuid>, std::allocator<boost::uuids::uuid> >::_M_erase(std::_Rb_tree_node<boost::uuids::uuid>*)()
#5 0x08056367 in std::_Rb_tree<boost::uuids::uuid, boost::uuids::uuid, std::_Identity<boost::uuids::uuid>, std::less<boost::uuids::uuid>, std::allocator<boost::uuids::uuid> >::_M_erase(std::_Rb_tree_node<boost::uuids::uuid>*)()
#6 0x001ceb8c in vsdk::radius::CRadiusAttribute::~CRadiusAttribute()() from ./libRadiusHandler.so
#7 0x001d5a33 in vsdk::radius::CRadiusMsg::~CRadiusMsg()() from ./libRadiusHandler.so
#8 0x001d3509 in boost::detail::sp_counted_impl_pd<vsdk::radius::CRadiusClientReq*, vsdk::radius::CRadiusClientReq::Deleter>::dispose()() from ./libRadiusHandler.so
#9 0x08055d48 in boost::detail::shared_count::~shared_count()()
#10 0x001d1eff in vsdk::radius::CRadiusClientHandler::handleRecv(ACE_INET_Addr const&, ACE_INET_Addr const&, ACE_Message_Block&, bool&)() from ./libRadiusHandler.so
#11 0x001e27ba in vsdk::radius::CUdpMsg::run()() from ./libRadiusHandler.so
#12 0x001c8a9c in vsdk::radius::CHandlerMgr::svc()() from ./libRadiusHandler.so
#13 0x00d55172 in ACE_Task_Base::svc_run (args=0x96f24d8) at Task.cpp:271
#14 0x00d56798 in ACE_Thread_Adapter::invoke_i (this=0x9737168) at Thread_Adapter.cpp:161
#15 0x00d56835 in ACE_Thread_Adapter::invoke (this=0x9737168) at Thread_Adapter.cpp:96
#16 0x00cefa31 in ace_thread_adapter (args=0x9737168) at Base_Thread_Adapter.cpp:122
#17 0x00aeba49 in start_thread() from /lib/libpthread.so.0
#18 0x009fbaee in clone() from /lib/libc.so.6
(gdb)
似乎在std::set<boost::uuids::uuid>的析構函數。爲什麼？
這裏是我的代碼，一些不重要的代碼被省略：
class CRadiusClientReq
{
private:
CRadiusMsg m_radiusMsg; ///< radius msg
};
typedef boost::shared_ptr<CRadiusClientReq> CSpCRadiusClientReq;
class CRadiusMsg
{
private:
static const uint32_t MAX_ATTR_NUM = 23;
CRadiusAttribute m_attributes[MAX_ATTR_NUM];
};
class CRadiusAttribute
{
private:
EAttributeType m_type;
uint32_t m_uint32;
uint8_t m_array[CHAP_PASSWORD_LEN];
std::string m_string;
std::set<boost::uuids::uuid> m_resSet; // seems core dump in free this member
};
class CRadiusRequestRspWaitMgr
{
public:
bool queryRequest(const uint8_t id, CSpCRadiusClientReq & spRadiusClientReq)
{
// lock
boost::mutex::scoped_lock l(m_mutex);
RadiusRequestRspWaitMap::iterator itr = m_requestRspWaitMap.find(id);
if (m_requestRspWaitMap.end() == itr)
{
// not found
return false;
}
spRadiusClientReq = itr->second;
if (!spRadiusClientReq)
{
return false;
}
return true;
}
bool delRequest(const uint8_t id)
{
boost::mutex::scoped_lock l(m_mutex);
RadiusRequestRspWaitMap::iterator itr = m_requestRspWaitMap.find(id);
if (m_requestRspWaitMap.end() == itr)
{
// not found
return false;
}
// erase it
m_requestRspWaitMap.erase(itr);
return true;
}
private:
typedef std::map< uint8_t, CSpCRadiusClientReq> RadiusRequestRspWaitMap;
RadiusRequestRspWaitMap m_requestRspWaitMap; // requests which is waiting response.
boost::mutex m_mutex; //
};
class CRadiusClientHandler
{
private:
CRadiusRequestRspWaitMgr m_authReqRspWaitMgr; ///< auth rsp wait manager
CRadiusRequestRspWaitMgr m_acctReqRspWaitMgr; ///< acct rsp wait manager
};
void CRadiusClientHandler::handleRecv(const ACE_INET_Addr& localAddr, const ACE_INET_Addr& peer, ACE_Message_Block& msg, bool &bReuse)
{
// set reuse this message block
bReuse = true;
uint8_t *buf = (uint8_t*)msg.rd_ptr();
uint32_t len = msg.length();
if (len < 20)
{
return;
}
// read code and id.
uint8_t code = buf[0];
uint8_t id = buf[1];
CRadiusRequestRspWaitMgr *rspWaitMgr = 0;
if (D_PACKET_ACCESS_ACCEPT == code
|| D_PACKET_ACCESS_REJECT == code)
{
// auth response
if (localAddr.get_port_number() != m_srcAuthPort)
{
// not auth port
return;
}
// set rspWaitMgr
rspWaitMgr = &m_authReqRspWaitMgr;
}
else if (D_PACKET_ACCOUNTING_RESPONSE == code)
{
// acct response
if (localAddr.get_port_number() != m_srcAcctPort)
{
// not acct port
return;
}
// set rspWaitMgr
rspWaitMgr = &m_acctReqRspWaitMgr;
}
else
{
// error type msg
return;
}
// find a match request in waiting response queue
CSpCRadiusClientReq spClientReq;
if (!rspWaitMgr->queryRequest(id, spClientReq)
|| !spClientReq)
{
return;
}
// some handle process code here, omitted.
...
// delete request in waiting response queue
rspWaitMgr->delRequest(id);
}
int32_t CUdpMsg::run()
{
if (!m_udpMsgNotify)
{
return -1;
}
bool bReuse = true;
m_udpMsgNotify->handleRecv(m_localAddr, m_srcAddr, *m_aceMb, bReuse);
if (bReuse)
{
delete m_aceMb;
m_aceMb = 0;
}
return 0;
}
// send request
bool CRadiusClientHandler::sendNonLoginAuthReq(const std::string & userName
, const uint8_t chapId
, const boost::array<uint8_t,16> & chapChallenge
, const boost::array<uint8_t,16> & pwdCaculated
, const boost::array<uint8_t,16> & uid
, const uint32_t authority
, const std::set<boost::uuids::uuid> & resIds
, uint8_t & authId
, EClientHandlerError & result)
{
result = ECLIENTHANDLERERROR_FAIL;
CSpCRadiusClientReq spRadiusClientReq(new CRadiusClientReq());
if (!spRadiusClientReq)
{
return false;
}
CRadiusMsg &radiusMsg = spRadiusClientReq->getRadiusMsg();
// set the boost
if (!radiusMsg.setResList(resIds))
{
result = ECLIENTHANDLERERROR_RESNUM_OVERTOP;
return false;
}
// some other unimportant codes, include generate reqId, omitted.
uint8_t reqId = 0;
...
// add to rspWaitMgr
if (!m_authReqRspWaitMgr.addRequest(reqId, spRadiusClientReq))
{
return false;
}
// some other unimportant codes, include message sending, omitted.
...
// return reqId
authId = reqId;
result = ECLIENTHANDLERERROR_SUCCESS;
return true;
}
CRadiusClientHandler::handleRecv處理接收到的UDP數據包。它在rspWaitMgr中找到匹配請求spClientReq，這是等待響應的所有請求池。
在CRadiusClientHandler::handleRecv完成並退出範圍後，spClientReq自動刪除保存在此shared_ptr中的指針。
而且我在shared_ptr中使用了所有的指針。我認爲boost::shared_ptr是線程安全的。所以我看不到任何雙重自由。
在CRadiusClientHandler我有兩個成員m_authReqRspWaitMgr和m_acctReqRspWaitMgr。根據收到的消息類型，我選擇使用哪一種。
所以當這個核心轉儲發生時，這兩個成員仍然存在。而且我只有一個CRadiusClientHandler的實例，它將在我的程序退出時被刪除。
這裏是我的分析。
這些都是_int_free拆解代碼：
0x0098bff8 <+152>: shr $0x3,%edi
0x0098bffb <+155>: mov %ecx,%eax
0x0098bffd <+157>: sub $0x2,%edi
0x0098c000 <+160>: mov 0x8(%eax,%edi,4),%edx
0x0098c004 <+164>: lea 0x8(%ecx,%edi,4),%ecx
0x0098c008 <+168>: mov %edi,-0x10(%ebp)
0x0098c00b <+171>: cmp %edx,%esi
0x0098c00d <+173>: je 0x98c514 <_int_free+1460>
0x0098c013 <+179>: mov $0xffffffff,%edi
0x0098c018 <+184>: jmp 0x98c02a <_int_free+202>
0x0098c01a <+186>: nopw 0x0(%eax,%eax,1)
0x0098c020 <+192>: cmp %eax,%esi
0x0098c022 <+194>: mov %eax,%edx
0x0098c024 <+196>: je 0x98c514 <_int_free+1460>
0x0098c02a <+202>: test %edx,%edx
0x0098c02c <+204>: je 0x98c037 <_int_free+215>
=> 0x0098c02e <+206>: mov 0x4(%edx),%edi
0x0098c031 <+209>: shr $0x3,%edi
0x0098c034 <+212>: sub $0x2,%edi
0x0098c037 <+215>: mov %edx,0x8(%esi)
0x0098c03a <+218>: mov %edx,%eax
0x0098c03c <+220>: cmpl $0x0,%gs:0xc
0x0098c044 <+228>: je 0x98c047 <_int_free+231>
0x0098c046 <+230>: lock cmpxchg %esi,(%ecx)
0x0098c04a <+234>: cmp %eax,%edx
0x0098c04c <+236>: jne 0x98c020 <_int_free+192>
0x0098c04e <+238>: test %edx,%edx
0x0098c050 <+240>: je 0x98c05b <_int_free+251>
0x0098c052 <+242>: cmp -0x10(%ebp),%edi
0x0098c055 <+245>: jne 0x98c5a9 <_int_free+1609>
我嘗試匹配malloc.c（的glibc-2.12.1）的源代碼，也許在這裏：
set_fastchunks(av);
unsigned int idx = fastbin_index(size);
fb = &fastbin (av, idx);
#ifdef ATOMIC_FASTBINS
mchunkptr fd;
mchunkptr old = *fb;
unsigned int old_idx = ~0u;
do
{
/* Another simple check: make sure the top of the bin is not the
record we are going to add (i.e., double free). */
if (__builtin_expect (old == p, 0))
{
errstr = "double free or corruption (fasttop)";
goto errout;
}
if (old != NULL)
old_idx = fastbin_index(chunksize(old)); **-------- maybe core dump here**
p->fd = fd = old;
}
while ((old = catomic_compare_and_exchange_val_rel (fb, p, fd)) != fd);
if (fd != NULL && __builtin_expect (old_idx != idx, 0))
{
errstr = "invalid fastbin entry (free)";
goto errout;
}
#else
/* Another simple check: make sure the top of the bin is not the
record we are going to add (i.e., double free). */
if (__builtin_expect (*fb == p, 0))
{
errstr = "double free or corruption (fasttop)";
goto errout;
}
if (*fb != NULL
&& __builtin_expect (fastbin_index(chunksize(*fb)) != idx, 0))
{
errstr = "invalid fastbin entry (free)";
goto errout;
}
p->fd = *fb;
*fb = p;
#endif
似乎變量old指向一個無效的地址。
寄存器信息是：
(gdb) info register
eax 0xb5d00010 -1244659696
ecx 0xb5d00024 -1244659676
edx 0xb4304ce8 -1271903000
ebx 0xaabff4 11190260
esp 0xb6179a84 0xb6179a84
ebp 0xb6179ad8 0xb6179ad8
esi 0xb5d235e0 -1244514848
edi 0xffffffff -1
eip 0x98c02e 0x98c02e <_int_free+206>
eflags 0x10286 [ PF SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb) x /8xw 0xb4304ce8
0xb4304ce8: Cannot access memory at address 0xb4304ce8
(gdb)
根據源代碼和反彙編代碼，我有以下結論： -The %eax是av。 -The %ecx是fb。 -The %edi是old_idx。 -The %esi是內存塊需要是免費的。
%edi仍然是初始值0xFFFFFFFF，所以我覺得這是第一次進入循環。 根據mchunkptr old = *fb，可能%edx等於地址%ecx的內容。 但現在，%edx（old）是0xb4304ce8，地址%ecx（*fb）的含量爲0xb5d5a958。他們是不同的。
(gdb) x /8xw 0xb5d00024
0xb5d00024: 0xb5d5a958 0xb5dc3088 0x00000000 0x00000000
0xb5d00034: 0x00000000 0x00000000 0x00000000 0xb45d9208
(gdb)
而且我注意到av是0x00000002的flags，這意味着沒有fastbin？
(gdb) x /8xw 0xb5d00010
0xb5d00010: 0x00000000 0x00000002 0x00000000 0xb5ddc848
0xb5d00020: 0xb5d5e4f8 0xb5d5a958 0xb5dc3088 0x00000000
(gdb)
而且我也注意到這些評論：
/*
FASTCHUNKS_BIT held in max_fast indicates that there are probably
some fastbin chunks. It is set true on entering a chunk into any
fastbin, and cleared only in malloc_consolidate.
The truth value is inverted so that have_fastchunks will be true
upon startup (since statics are zero-filled), simplifying
initialization checks.
*/
所以我認爲，當前線程後，再執行mchunkptr old = *fb;，其他線程觸發malloc_consolidate清潔和fastbin鞏固塊。
那麼也許會通過%edx記憶點已trimed或釋放。但是有可能嗎？
我對glibc的內存管理一知半解，也許一些人可以減輕我的懷疑。
這裏是操作系統的信息：
[[email protected] log]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
[[email protected] log]# uname -a
Linux mdssdk 2.6.32-358.el6.i686 #1 SMP Tue Jan 29 11:48:01 EST 2013 i686 i686 i386 GNU/Linux
[[email protected] log]#
最後，我下載glibc的最新版本2.24，並發現真正的原因。這是一個錯誤，並在glibc 2.19中修復。
固定代碼在這裏：
set_fastchunks(av);
unsigned int idx = fastbin_index(size);
fb = &fastbin (av, idx);
/* Atomically link P to its fastbin: P->FD = *FB; *FB = P; */
mchunkptr old = *fb, old2;
unsigned int old_idx = ~0u;
do
{
/* Check that the top of the bin is not the record we are going to add
(i.e., double free). */
if (__builtin_expect (old == p, 0))
{
errstr = "double free or corruption (fasttop)";
goto errout;
}
**/* Check that size of fastbin chunk at the top is the same as
size of the chunk that we are adding. We can dereference OLD
only if we have the lock, otherwise it might have already been
deallocated. See use of OLD_IDX below for the actual check. */**
if (have_lock && old != NULL)
old_idx = fastbin_index(chunksize(old));
p->fd = old2 = old;
}
while ((old = catomic_compare_and_exchange_val_rel (fb, p, old2)) != old2);
if (have_lock && old != NULL && __builtin_expect (old_idx != idx, 0))
{
errstr = "invalid fastbin entry (free)";
goto errout;
}
的問題應該在你的代碼，而不是''malloc'或boost''的std :: set'，它應該是雙自由'＃10 VSDK ::半徑:: CRadiusClientHandler 0x001d1eff某處:: handleRecv'和'＃11 0x001e27ba在vsdk :: radius :: CUdpMsg :: run'中，這是C++，而不是C – Danh
請正確格式化您的代碼 –
對不起，錯誤代碼和抱歉的代碼格式。我從malloc.c複製它。而在這些代碼中，製表符和空格混合在一起，所以看起來很糟糕。我已經重新格式化了它們。我添加了一些實現代碼。我找不到任何雙倍免費。不正確？ –