Print

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

[DeeJay(HUN)]

Hi all,

I'm trying to get aMule 2.2.2 work on OpenWRT Kamikaze 7.09, on the mipsel platform (WL-500gP). I am using the Unslung build framework for building aMule, downloaded prebuilt unslung packages for its dependecies, and I built OpenWRT also myself from sources. I noticed the prebuilt unslung mipsel package is not working, but after removing optimizations for crypto++, and amule, I got halfway decent results, aMule is starting up, it does what it is supposed to do, but after an hour or so, one of the threads saturates the processor completely. I attached to it with GDB, and it shows that aMule got stuck in the logf function, maybe running in endless loop? I'm using kernel 2.4.34, gcc 3.4.6, libuclibc++-0.2.2-r18737, wxbase-2.8.7.

I would be intrested in your opinions, I'm not sure how to handle thing from now on, I can't decide if this is an aMule problem or a standard library problem. Also according to ldd, my amuled executable seems to be linked with both libstdc++, and libuclibc++, which is used then for logf?

See my gdb output here, I was able to reproduce this twice, so it is not just by chance that it is sitting in logf() I think.

(gdb) bt
#0  0x00c4d400 in logf ()
#1  0x007b0948 in CUpDownClient::CalculateKBpsDown ()
#2  0x0073fbec in CUpDownClient::SetDownloadLimit ()
#3  0x00991250 in CPartFile::Process ()
#4  0x007c64dc in CDownloadQueue::Process ()
#5  0x0072e0e8 in CamuleApp::OnCoreTimer ()
#6  0x2ad3dc88 in wxEvtHandler::ProcessEventIfMatches () from /opt/lib/libwx_baseu-2.8.so.0
#7  0x2ad3e198 in wxEventHashTable::HandleEvent () from /opt/lib/libwx_baseu-2.8.so.0
#8  0x2ad3f3f4 in wxEvtHandler::ProcessEvent () from /opt/lib/libwx_baseu-2.8.so.0
#9  0x2ad3f094 in wxEvtHandler::ProcessPendingEvents () from /opt/lib/libwx_baseu-2.8.so.0
#10 0x2ac4b970 in wxAppConsole::ProcessPendingEvents () from /opt/lib/libwx_baseu-2.8.so.0
#11 0x0071f84c in CamuleDaemonApp::OnRun ()
#12 0x2aca3d04 in wxEntry () from /opt/lib/libwx_baseu-2.8.so.0
#13 0x0071db14 in main ()
(gdb) bt full
#0  0x00c4d400 in logf ()
No symbol table info available.
#1  0x007b0948 in CUpDownClient::CalculateKBpsDown ()
No symbol table info available.
#2  0x0073fbec in CUpDownClient::SetDownloadLimit ()
No symbol table info available.
#3  0x00991250 in CPartFile::Process ()
No symbol table info available.
#4  0x007c64dc in CDownloadQueue::Process ()
No symbol table info available.
#5  0x0072e0e8 in CamuleApp::OnCoreTimer ()
No symbol table info available.
#6  0x2ad3dc88 in wxEvtHandler::ProcessEventIfMatches () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#7  0x2ad3e198 in wxEventHashTable::HandleEvent () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#8  0x2ad3f3f4 in wxEvtHandler::ProcessEvent () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#9  0x2ad3f094 in wxEvtHandler::ProcessPendingEvents () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#10 0x2ac4b970 in wxAppConsole::ProcessPendingEvents () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#11 0x0071f84c in CamuleDaemonApp::OnRun ()
No symbol table info available.
#12 0x2aca3d04 in wxEntry () from /opt/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#13 0x0071db14 in main ()
No symbol table info available.

(gdb) thread apply all bt
(gdb) interrupt
(gdb) step
Single stepping until exit from function logf,
which has no line number information.

Here gdb just hangs, I do not get the prompt back for a very long time.

Thanks for your help in advance.

Best regards,

DeeJay

[Stu Redman]

Hmm - this code might be kind of inefficient on platforms without native floating point (and isn't that true for Mipsel ?).

Try

Code: [Select]

float CUpDownClient::CalculateKBpsDown()
{
// -- all timing values are in seconds --
const float tcLoop   =  0.1f; // _assumed_ Process() loop time = 0.1 sec
const float tcInit   =  0.4f; // initial filter time constant
const float tcFinal  = 50.0f; // final filter time constant
const float tcReduce =  5.0f; // transition from tcInit to tcFinal

const float fInit  = tcLoop/tcInit; // initial averaging factor
const float fFinal = tcLoop/tcFinal; // final averaging factor
static float fReduce = 0.0f;
if (fReduce == 0.0f) {
fReduce = std::exp(std::log(fFinal/fInit) / (tcReduce/tcLoop)) * 0.99999;
}
and see if the problem goes away.

[GonoszTopi]

Will be fixed in 2.3.0.

[DeeJay(HUN)]

Hi All,

I finally got my computer back from the service, and had a chance  to test the suggested modifications. This does not seem to help, what it does is that amuled gets into the endless loop much faster, right after the first client connection attempt. I suspect the underlying implementation of logf has some problem, so maybe it is not a good idea to include this change into 2.3.0.

I will look around, maybe there is some lightweight float implementation, with which this call can be replaced, but I doubt that I will find one, which is faster than the C library.

Can the frequency with which this function is called be reduced?

Thanks for your help!

DeeJay

[Stu Redman]

Can the frequency with which this function is called be reduced?

With the patch, logf() is only called once so the frequency has no effect.
Throw out the calculation and set fReduce to 0.90794069 (that's what the const expression evaluates to) and see if that helps.

[DeeJay(HUN)]

With the patch, logf() is only called once so the frequency has no effect.
Throw out the calculation and set fReduce to 0.90794069 (that's what the const expression evaluates to) and see if that helps.

Thanks, this one did really help. aMule was up and running whole night on the router, it also managed to download something, so I think it is safe to say that the problem indeed was the underlying logf() implementation. I plan to send a mail about this issue to the libuclibc++ guys.

I probably also will send a patch with setting fReduce to 0.90794069 to the unslung guys, if there are no objections.

Thanks again, I really appreciate your help.

[Stu Redman]

I probably also will send a patch with setting fReduce to 0.90794069 to the unslung guys, if there are no objections.

That's not necessary - the whole piece of code has been replaced meanwhile. They just have to update to 2.2.3 when it comes out (which is soon).

[lfroen]

Will be fixed in 2.3.0.

Be careful here. The code there implements low-pass filter. Implementing it in integer operation and not loosing presicion may be not trivial.

[Stu Redman]

It was loosing pretty much precision alright. That's why I replaced it.

[Kry]

Given our opinion on Adunanza, any further talk about it will have to be done in PM or move yourselves to their forum, and this is the last warning. Further Adunanza talk will be directly banned - it's bad enough to harm the network, that you also have to come here to request help from the testers/developers.