linuxdcpp-team team mailing list archive
-
linuxdcpp-team team
-
Mailing list archive
-
Message #00088
[Bug 442475] Re: Crash when adding search result from user who has left the hub
aww, what did Steven do? He was against the whole idea.
Anyway back to the subject. Of course you're right, if we moved the
duplicate checking to ::on function results map wouldn't need to be
accessed from the _gui and it could be used within the other _client
functions. Though I'd still rather dispatch a SearchResultPtr instead of
StringMap and convert the pointer to presentable strings in _gui
(because ptr is just much lighter to pass around than the map (I don't
know if this has that big of an effect on performance, I'll have to
check)).
And at the same note, I don't think that changing the _client functions
to use results map instead of findUser has that big of an effect on
performance since the client functions are called from user actions and
thus are quite rare (compared to addResult).
But that being said, I'll move the duplicate check to _client and remove
the findUser calls. Depending on performance measurement results I'll
change the StringMap passing back also.
--RZ
--
Crash when adding search result from user who has left the hub
https://bugs.launchpad.net/bugs/442475
You received this bug notification because you are a member of LinuxDC++
Team, which is subscribed to LinuxDC++.
Status in Linux DC++: Fix Committed
Bug description:
Linuxdcpp crashes when trying to download a search result from a user who has left the hub. The crash doesn't happen if the result is added to the queue immediately after the user leaves, but minute or two should be enough, after that attempt to add result to the queue leads to crash (or assert failure with debug builds).
BT From debug build:
#0 0xb7f73424 in __kernel_vsyscall ()
#1 0xb75c1660 in raise () from /lib/libc.so.6
#2 0xb75c2e98 in abort () from /lib/libc.so.6
#3 0xb75ba6ce in __assert_fail () from /lib/libc.so.6
#4 0x0809fd8b in boost::intrusive_ptr<dcpp::User>::operator* (this=0xb48bf284) at /usr/include/boost/intrusive_ptr.hpp:120
#5 0x0809fda3 in dcpp::User::Hash::operator() (this=0x8f918ce, x=@0xb48bf284) at dcpp/User.h:64
#6 0x082138fb in std::tr1::__detail::_Hash_code_base<boost::intrusive_ptr<dcpp::User>, std::pair<boost::intrusive_ptr<dcpp::User> const, dcpp::QueueItem*>, std::_Select1st<std::pair<boost::intrusive_ptr<dcpp::User> const, dcpp::QueueItem*> >, std::equal_to<boost::intrusive_ptr<dcpp::User> >, dcpp::User::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, false>::_M_hash_code (this=0x8f918cc,
__k=@0xb48bf284) at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/hashtable_policy.h:697
#7 0x08213916 in std::tr1::_Hashtable<boost::intrusive_ptr<dcpp::User>, std::pair<boost::intrusive_ptr<dcpp::User> const, dcpp::QueueItem*>, std::allocator<std::pair<boost::intrusive_ptr<dcpp::User> const, dcpp::QueueItem*> >, std::_Select1st<std::pair<boost::intrusive_ptr<dcpp::User> const, dcpp::QueueItem*> >, std::equal_to<boost::intrusive_ptr<dcpp::User> >, dcpp::User::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, false, true>::find (this=0x8f918cc, __k=@0xb48bf284)
at /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/tr1_impl/hashtable:762
#8 0x08202771 in dcpp::QueueManager::UserQueue::getRunning (this=0x8f9180c, aUser=@0xb48bf284) at dcpp/QueueManager.cpp:273
#9 0x08207dd7 in dcpp::QueueManager::addSource (this=0x8f91708, qi=0x978b000, aUser=@0xb48bf284, addBad=991) at dcpp/QueueManager.cpp:685
#10 0x0820de72 in dcpp::QueueManager::add (this=0x8f91708, aTarget=@0xb48bf2b8, aSize=4696548889, root=@0xb48bf2a0, aUser=@0xb48bf284,
hubHint=@0xb48bf31c, aFlags=0, addBad=true) at dcpp/QueueManager.cpp:626
#11 0x080ed3bf in Search::download_client (this=0x9706870, target=
{static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xb48bf32c "#A#b#\214#x#\th#213#"}}, cid=
{static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xb48bf328 "<#\t#A#b#\214#x#\th#213#"}}, filename=
{static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xb48bf324 "<\201{\t<#\t#A#b#\214#x#\th#213#"}}, size=4696548889, tth=
{static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xb48bf320 "#~{\t<\201{\t<#\t#A#b#\214#x#\th#213#"}}, hubUrl=
{static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xb48bf31c "\204#q\t#~{\t<\201{\t<#\t#A#b#\214#x#\th#213#"}}) at linux/search.cc:1632
#12 0x081117ad in Func6<Search, std::string, std::string, std::string, long long, std::string, std::string>::call (this=0x97608b0)
at linux/func.hh:228
#13 0x08183b00 in WulforManager::processClientQueue (this=0x95009d8) at linux/wulformanager.cc:220
#14 0x08183bb9 in WulforManager::threadFunc_client (data=0x95009d8) at linux/wulformanager.cc:160
#15 0xb785e33f in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x095009d8 in ?? ()
#17 0x094ff678 in ?? ()
#18 0x00000000 in ?? ()
Now, should we check the return value of that userPtr that is passed to QueueManager::add? By checking if the user.get() != 0. But it should still be possible to add result even if the original source has left (I guess there isn't and QM:add without userPtr?). Or should we store the UserPtrs (or SearchResultPtrs?) while the result list is open? (if I remember correctly dc++ stored the SearchResults in the tab while they were being displayed).
--RZ