Print

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

[GuybrushThreepwood]

@GonoszTopi
Thanks for your advices: I would follow them.

Bad news, again! Even 9586 makes the swap crash: how is this possible? I've built several aMule versions (stable ones too but mostly SVN ones) before 9548 and everything was always fine (with 9548 included as already said; I've recently rebuilt 9548 adding the logging feature for discarded packets and it's still fine, this confirming that my build environment is ok). Why every newer version has some kind of issue?
By the way, 9586 behaves exactly as 9960: poor, very poor download speeds, erratic upload speeds and the general sensation that aMule is struggling up to the swap crash (aMule, the ADSL carrier and the rest are still "fine" but the swap crashes; when I try to do the swapoff it says that it cannot allocate memory and I need to reboot the router as always).
9586 isn't much newer than 9548: I'm really starting to fear that I would end up with building 9549... Next candidate is 9567. Just a doubt, are my installed dependencies:

http://forum.amule.org/index.php?PHPSESSID=7925dbe2a8ad143cd2420881c9b8f855&topic=16721.msg88778#msg88778

still fine (I guess so otherwise I might receive errors when configuring) or do I need to update anything? I've already pointed out this in the previous posts but I ask this again, just to be sure. Is this modification:

http://forum.amule.org/index.php?topic=16721.msg88939#msg88939

(I've succesfully applied it up to 9548, without it I can't handle downloads which size is over 1Gb though someone has said that the newer versions, 9548 included and I can exclude this because I've tried, don't suffer of this issue related to an incompatibility with older versions of uclibc like the one inlcuded in my toolchain) legitimate or could it be the cause of my problems?
Just a last wild guess: could this issue be related to a faulty swap partition? Maybe the newer versions require more swap space and they reach a damaged swap area that wasn't reached before... Apart from the fact that I've checked the swap and everything is reported to be fine, I find this explanation very arguable. Thanks for your help: I REALLY appreciate your effort!

[Stu Redman]

Now what do we have in this range ?
- signal handler for mmap (introduced in 9549, fixed and attached to configure option in 9563)
- autoclose of partfiles to reduce file handles (9585)

Try 9584 (or 9563 or something in between,  doesn't matter which).
Or try current SVN and patch FileArea.cpp:

Code: [Select]

//#if !defined(HAVE_SIGACTION) || !defined(SA_SIGINFO) || !defined(HAVE_MMAP)
#if 1

class CFileAreaSigHandler
{


[GuybrushThreepwood]

Thanks for your reply. I would try the latest SVN patching it as you've suggested. In the meantime, I've rebuilt 9548 and I'm testing it: by now it's rock solid as always. It isn't certainly a build environment issue...
Could I continue patching amule.cpp as described? Do you think that disabling the CorruptionBlackBox could help? I've tried 9960 with and without it with no evident changes... My idea is to build the latest SVN

1) patching amule.cpp as always
2) patching MuleUDPSocket.cpp to disable the logging of discarded packets (just to keep the log file clean, this is certainly an irrelevant modification)
3) patching FileArea.cpp as you've suggested

What do you think?

[Stu Redman]

Leave CorruptionBlackBox alone. 9586 failed too, and that was before CBB was introduced.

[GuybrushThreepwood]

As said, I was already planning to leave PartFile.cpp untouched but thanks for your confirmation. I would keep you updated...

[GuybrushThreepwood]

I've just built 9970 patching FileArea.cpp as you've suggested (I've patched amule.cpp and MuleUDPSocket.cpp as always too) and things are even worse now: the swap crashes after only one hour (I don't know if this is just a coincidence).

[Stu Redman]

Then try 9584 (or less) without patching filearea.cpp. If this works it's the file autoclose feature that's causing the trouble (though I have no idea why yet).

[GuybrushThreepwood]

Then try 9584 (or less) without patching filearea.cpp. If this works it's the file autoclose feature that's causing the trouble (though I have no idea why yet).

Hello everyone! First of all, excuse me for my long absence but I had some problems and hadn't found the time to build 9584 before... Finally, I've managed to build 9584 and everything seems (I'm still testing it) to be fine like with 9548. What does this mean? Can I forget to use the newer versions or is making some modifications to the source code possible? I remember that Stu Redman was talking about the file autoclose feature... Thanks for your reply and have a good day!

[Stu Redman]

So it's the file autoclose. Hm.

One thing: iirc there is a global limit for file handles and network connections in amuled. autoclose greatly reduces used file handles and thus allows for more network connections. Which could be what is breaking your router...
What is your setting for maximum number of network connections? Can you check how many are actually open both with working and not working versions?

[GuybrushThreepwood]

As always, thanks for your great effort: I REALLY REALLY appreciate your help! Sad to say but 9584 doesn't work neither. I've tested it for fourteen hours of continuous usage: it has worked well (good general stability and download speeds) for at least ten hours (this alone was certainly better than what achieved by the other versions apart from the 9548) but, after fourteen hours and after completing a download (that's always a very heavy task so it could be the reason though I don't believe this because it doesn't happen with 9548), the router has stated to struggle (the ADSL connection was still up and working but the hard drive connected to the router didn't stop reading/writing for a single second) in fact, as I expected, the swap had crashed: as always, when I've tried to call the swapoff command, I've received the 'Couldn't allocate memory' error message in response and I could only reboot the router.
Now I ask to you: is there any RELEVANT modification between 9548 and 9584??? Next candidate is 9566: as I've feared in one of my previous posts, I would end up with building 9549... Is it possible that the latest working version on my router is 9548??? I remember that 9548 has a bug that causes corrupted packets to be sent: could be the solution to that bug the cause? If I remember well, I've patched 9548 for that bug and it still was ok. By the way, tomorrow I would test 9584 again to see if it would make the swap crash again.

What is your setting for maximum number of network connections? Can you check how many are actually open both with working and not working versions?

I would post the informations that you're asking for ASAP.

[Stu Redman]

I'm asking again: did you enable memory mapping ?
Also, please answer my questions.

[GuybrushThreepwood]

I'm asking again: did you enable memory mapping ?
Also, please answer my questions.

Excuse me: I didn't mean to neglect anything but you didn't speak about memory mapping in your last post. At least this point is already more than clear: I ALWAYS enable memory mapping by the --enable-mmap configure switch.
Today, I'm testing the older 9548 and it's proving to be very stable as always: the swap is still fine and here are the details that you've asked for (in your last post you did ask for these informations but not anything about memory mapping otherwise I had replied promptly and with the best detail possible as I've always tried to do):

I use these settings:
MaxConnections=500
MaxConnectionsPerFiveSeconds=10

and this is what I get:
Active connections: 68
Average connections: 58.57
Peak connections: 108
Limit reached: never

Everything seems fine (at least with 9548). I would continue to follow 9548 behaviour during this day and tomorrow I would do the same with 9584. Please advice if you need me to make some modifications or monitor some other aspects. Have a good day!

[Stu Redman]

Just wanted to make sure about the mmap. It has been a while... 

When you run in problems with 9584, lower you MaxConnections to 100 or even 70 and retry.

[GuybrushThreepwood]

When you run in problems with 9584, lower you MaxConnections to 100 or even 70 and retry.

I had already tried to lower the MaxConnections value to 100 with other versions and it didn't help but I would try, maybe lowering it to 70 as you suggest though I fear that it could be a too low value. By the way, lowering the Max Connections value could help only if  I would see that the connections number goes often near or over that limit while using 9584 otherwise this tweak wouldn't affect anything.
9548 is still working fine (as expected! This was the version that I've used more than any other so far and it always proved to be very stable: it's only that I'd like to take advantage of the improvements included in the newest versions though I'm starting to fear that I wouldn't... )

[GuybrushThreepwood]

There are some news... I've stopped testing 9548 (it was only a waste of time as it was still working perfectly as always) and anticipated the planned testing on 9584. I've also reduced the MaxConnections value to 100 but, after only a couple of hours, the hard disk connected to the router has started to struggle again: sure to see that something was wrong, I've opened aMuleGUI and seen that everything was messed up (erratic upload speed, zero download speed and all the dowloads had lost their respective queues). This time, I've noticed something interesting in the logfile that I don't remember to have seen before:

Code: [Select]

2010-06-01 21:45:59: Invalid Kad tag; type=0x09 name=

Two messages exactly like this were reported in twenty minutes. As always, I couldn't successfully complete the swapoff command: "cannot allocate memory" as expected. I hope that this is something new that could shed some light on this issue...