Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Attila]

I've managed to compile 20071222 but it's very unstable and crashes shortly after starting up. I'm running Debian Lenny with a .6.22-3-686 kernel and gcc 4.1. I compiled wxALL 2.8.7 from source using the --enable-unicode switch. I then compiled amule with no errors but now I guess the error when running amule from the console:

Code: [Select]

initialising aMule
Checking if there is an instance already running...
No other instances are running.
HTTP download thread started
Loading temp files from /home/xxx/.aMule/Temp.
Loading PartFile 1 of 1
All PartFiles Loaded.
ListenSocket: Ok.

External connections disabled in config file
*** Server UDP socket (TCP+3) at 0.0.0.0:4665
*** TCP socket (TCP) listening on 0.0.0.0:4662
*** Client UDP socket (extended eMule) at 0.0.0.0:4672
Adding file /home/xxx/.aMule/Temp/007.part.met to shares
Empty dir /home/xxx/.aMule/Incoming/ shared
HTTP download thread started
Host: amule.sourceforge.net:80
URL: http://amule.sourceforge.net/lastversion
Response: 200 (Error: 0)
Download size: 6
HTTP download thread ended
Host: emulepawcio.sourceforge.net:80
URL: http://emulepawcio.sourceforge.net/nieuwe_site/Ipfilter_fakes/ipfilter.dat
Response: 302 (Error: 0)
Host: emulepawcio.sourceforge.net:80
URL: http://emulepawcio.sourceforge.net/downloads/get.php?file=ipfilter.dat
Response: 302 (Error: 0)
Host: Auto-select.dl.sourceforge.net:80
URL: http://Auto-select.dl.sourceforge.net/sourceforge/emulepawcio/ipfilter.dat
Response: 302 (Error: 0)
Host: guide.opendns.com:80
URL: http://guide.opendns.com/?url=auto-select.dl.sourceforge.net%2Fsourceforge%2Femulepawcio%2Fipfilter.dat
Response: 200 (Error: 0)
Download size: -1
HTTP download thread ended
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/debug/vector:192:
    error: attempt to subscript container with out-of-bounds index 2, but
    container only holds 2 elements.

Objects involved in the operation:
sequence "this" @ 0x0xb507c0a0 {
  type = N15__gnu_debug_def6vectorIcSaIcEEE;
}
Aborted
I can do a full debug run and post it in the backtrace forum if need be.
Cheers,
Attila

[Stu Redman]

That's a bug in MuleUDPSocket.cpp line 253:
Old:

Code: [Select]

if (GetTickCount() - item.time < UDPMAXQUEUETIME) {
char sendbuffer[packet->GetPacketSize() + 2];
memcpy(sendbuffer, packet->GetUDPHeader(), 2);
memcpy(sendbuffer + 2, packet->GetDataBuffer(), packet->GetPacketSize());
New:

Code: [Select]

if (GetTickCount() - item.time < UDPMAXQUEUETIME) {
std::vector<char> sendbuffer(packet->GetPacketSize() + 2);
memcpy(&(sendbuffer[0]), packet->GetUDPHeader(), 2);
memcpy(&(sendbuffer[2]), packet->GetDataBuffer(), packet->GetPacketSize());
What's happening is a zero sized packed. memcpy works fine if it should copy zero bytes (and does nothing), but with the new code &(sendbuffer[2] fails now.
I've patched it up with

Code: [Select]

if (GetTickCount() - item.time < UDPMAXQUEUETIME && packet->GetPacketSize()) { // otherwise crash on zero sized packets (wherever they may come from)At least it hasn't crashed since.
Personally I do like plain arrays better than complicated classes, and this is a good example why. 
I just hope there aren't more bugs like this, because there are quite some changes of this sort in this version.

[Attila]

Thanks for that Sturedman. I'll wait a couple of days to see if there are more cases like that.
Cheers,
Attila

[Festor]

Note: The problem persists in the 20071223 CVS

[GrayFox.i0n]

Note: The problem persists in the 20071223 CVS

Agreed

[wuischke]

sturedman: I've committed your fix, thanks a lot.

[Stu Redman]

You're welcome! 

[Kry]

My bad. The reason the plain arrays were changed to std::vector is MSVC doesn't support variable size in array initializers (and actually ANSI doesn't, either, it's a GCC extension).

Would be cool if someone reviewed it all indeed. I actually need to review this fix, because it might not be right. Thanks anyway!

[Attila]

Thanks Kry. Is there any info I can provide that would be useful? If not I'll shut up and be patient.
Cheers,
Attila

[Kry]

Nto right onw, I'm afraid. Just keep testing!

[Stu Redman]

Would be cool if someone reviewed it all indeed. I actually need to review this fix, because it might not be right. Thanks anyway!

This bug would have slipped past any review because the code refactoring was fine and nobody would have thought of a zero sized packet beforehand probably. The fix is just a patch (literally speaking), the real fix should prevent trying to send zero sized packets.
Thank you for all the great work by the way !