aMule Forum
English => en_Bugs => Topic started by: byteforge on February 02, 2016, 12:52:05 AM
-
Running regular 2.4.0~git20151120.0023527bc2-1 on Ubuntu (Xenial) here.
Unlike the 2.3.1 build. this 2.4.0 one is suffering from a very nasty assertion bug which is not only a side effect, but will visible affect connection/disconnection of Kad. That is, amule might be still connected, bu everything that was blue before ( = available for downloading) has turned to red, and amule pretends to be no longer connected to Kad (wrong, but you WILL have to quit and restart amule to get things back to normal again, until the next assertion error comes up (very likely))
ASSERT INFO:
../../src/kademlia/net/KademliaUDPListener.cpp(527): assert "contactVersion >= 2" failed in Process2HelloRequest().
BACKTRACE:
[1] wxOnAssert(char const*, int, char const*, char const*, char const*)
[2] CryptoPP::IteratedHash<unsigned int, CryptoPP::EnumToType<CryptoPP::ByteOrder, 0>, 64u, CryptoPP::HashTransformation>::DataBuf()
[3] CryptoPP::IteratedHash<unsigned int, CryptoPP::EnumToType<CryptoPP::ByteOrder, 0>, 64u, CryptoPP::HashTransformation>::DataBuf()
[4] std::vector<unsigned short, std::allocator<unsigned short> >::_M_insert_aux(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned short const&)
[5] non-virtual thunk to CryptoPP::PK_FinalTemplate<CryptoPP::TF_SignerImpl<CryptoPP::TF_SignatureSchemeOptions<CryptoPP::TF_SS<CryptoPP::PKCS1v15, CryptoPP::SHA1, CryptoPP::RSA, int>, CryptoPP::RSA, CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> > >::~PK_FinalTemplate()
[6] std::vector<unsigned short, std::allocator<unsigned short> >::_M_insert_aux(__gnu_cxx::__normal_iterator<unsigned short*, std::vector<unsigned short, std::allocator<unsigned short> > >, unsigned short const&)
[7] non-virtual thunk to CryptoPP::PK_FinalTemplate<CryptoPP::TF_SignerImpl<CryptoPP::TF_SignatureSchemeOptions<CryptoPP::TF_SS<CryptoPP::PKCS1v15, CryptoPP::SHA1, CryptoPP::RSA, int>, CryptoPP::RSA, CryptoPP::PKCS1v15_SignatureMessageEncodingMethod, CryptoPP::SHA1> > >::~PK_FinalTemplate()
[8] wxSizer::Add(wxWindow*, int, int, int, wxObject*)
[9] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const
[10] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[11] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[12] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[13] wxEvtHandler::TryHereOnly(wxEvent&)
[14] wxEvtHandler::ProcessEventLocally(wxEvent&)
[15] wxEvtHandler::ProcessEvent(wxEvent&)
[16] wxEvtHandler::ProcessPendingEvents()
[17] wxAppConsoleBase::ProcessPendingEvents()
[18] wxApp::DoIdle()
[19] g_main_context_dispatch
[20] g_main_loop_run
[21] gtk_main
[22] wxGUIEventLoop::DoRun()
[23] wxEventLoopBase::Run()
[24] wxAppConsoleBase::MainLoop()
[25] wxAppConsoleBase::OnRun()
[26] wxAppBase::OnRun()
[27] wxEntry(int&, wchar_t**)
[28] wxEntry(int&, char**)
[29] __libc_start_main
-
Well thanks for reporting the bug. Hopefully someone will look into it if not already fixed.
aMule 2.3.1 is published under SR (Stable Release), where the aMule 2.4.0 is just compiled from SVN latest developmental source code tree and is not even RC (Release Candidate). So there is always going to be problem as its snapshot from active development tree.
-
Thanks for the quick reply. You might be right - that it is fixed in trunk.
At least the bug was not introduced until lately, that's for sure.
As the PPA guy had already deleted his older build in a haste, I was glad to find an "alien" version actually made for Arch:
amule-10871-2-i686.pkg.tar.xz
No single assertion error in this build so far - fingers crossed. I'm going to keep this version until a better 2.4.0-git build will be showing up sometime.