linuxdcpp-team team mailing list archive

[Razzloss <razzloss@xxxxxxxxx>]

Committed changes adding unordered_map<string (cid),
vector<SearchResultPtr> > and changes to addResult_gui. Didn't touch any
of the _client (except parseSearchResult_client which is now _gui.
Though I don't think it matters where this is called as long as the
ResultPtr is available) functions yet (and probably won't as using this
would require some locking mechanism). And most of the _gui callbacks
deal with iterators anyway from which they parse the needed data
together, so don't think any additional changes to _gui or _client
functions are worth it.

--RZ

** Changed in: linuxdcpp
       Status: Confirmed => Fix Committed

-- 
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