aMule Forum

English => en_Bugs => Topic started by: llama on November 10, 2008, 08:41:46 AM

Title: assert "contactVersion >= 1" failed in debug mode
Post by: llama on November 10, 2008, 08:41:46 AM
I run amule 2.2.2 compiled with --enable-debug, against wxGTK 2.8.9 (built from upstream source with debugging) on amd64 Ubuntu Intrepid.

 I got this assertion:
2008-11-10 03:08:28: Logger.cpp(275): Debug: ../../src/kademlia/net/KademliaUDPListener.cpp(697): assert "contactVersion >= 1" failed in Process2HelloRequest().

Code: [Select]
just the relevant stack frame, after selecting continue: no in the dialog box (copy/paste from less, so non-ascii bytes in the string are in <hex>):
#8  0x00000000005a683c in Kademlia::CKademliaUDPListener::Process2HelloRequest (this=0x83952f0,
    packetData=0x7fffcb3c4252 "!6<D4>?Y<C8><D4>?Y<C8>", lenPacket=514, ip=2091184209, port=5054, senderKey=@0x7fffcb3c40d0,
    validReceiverKey=false) at ../../src/kademlia/net/KademliaUDPListener.cpp:697
        dbgOldUDPPort = 5054
        contactVersion = 0 '\0'
        contactID = {m_data = {1070872097, 1070909529, 51289, 2031616}}
        addedOrUpdated = false
        __FUNCTION__ = "Process2HelloRequest"

(gdb) l
692     {
693             uint16_t dbgOldUDPPort = port;
694             uint8_t contactVersion = 0;
695             CUInt128 contactID;
696             bool addedOrUpdated = AddContact2(packetData, lenPacket, ip, port, &contactVersion, senderKey, validReceiverKey, true, true, NULL, &contactID); // might change (udp)port, validReceiverKey
697             wxASSERT(contactVersion >= 1);


I have the full backtrace if you want it, but presumably it received a packet with contactVersion = 0.  A log message would be appropriate, but even in debug mode where assertion failure are recoverable, I don't think "dieing" is an appropriate response to bad/malicious network input.

 In gdb, I hit "n" after I was done backtracing, and the thread exitted, and amule is still running.  I don't think I'll stop and re-start it, since I'm hoping it just (at worst) leaked some memory with the non-standard thread exit, and didn't corrupt any data structures.