Print

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

[JuhaManninen]

from what i read it a wxWidgets bug as it tries to calculate each block to upload and consumes memory until you have none left...thats why i limited mine and had no further out of memory problems...so it's not aMule just wxWidgets..check that [Upload full Chunks} is enables also...

HTH..

Sorry, where is this "Upload full Chunks" setting? I don't find it in Preferences or elsewhere.
What is "Slot allocation" in Bandwith Limits section? What value should it have?

Now I have understood that everyone limits the upload bandwith. It is possible that none of the developers has tried to run aMule without limiting it, not for many hours anyway. So, the bug may be very real, but only I noticed it because I was stupid enough not to limit the bandwith. :-)
Well, actually "hopelessone" had some similar problems, right.

[JuhaManninen]

Also, if the program died with SIGKILL and you did not explicitly "kill -9" it, then you have a very strange behaving system. "No stack" is equally strange, but is not related to having or not full debug information. It means that some serious error happened and gdb was not able to locate the stack.

My guess is that Linux kernel is clever enough to kill a process which is eating all memory for a long period of time. I didn't touch the machine, it all happened at night when I tried to sleep (although the hard drive noise half-woke me up).
All in all, Linux kernel has done its job very well. No other programs have been affected and it has always recovered from the all-memory-used situation.

[hopelessone]

1. its in the preferences>>files>>"Try to transfer full chunks to all uploads" <<-make sure it's enabled..

2.  preferences>>connection>>slot allocation

have a read of this http://ubuntuforums.org/showthread.php?t=526975&highlight=amule+tweak

hope helps..

[phoenix]

Hey,

from what i read it a wxWidgets bug as it tries to calculate each block to upload and consumes memory until you have none left...thats why i limited mine and had no further out of memory problems...so it's not aMule just wxWidgets..check that [Upload full Chunks} is enables also...

Hum, I am not saying that it is not related to this setting, but lets not start blaming wxWidgets on this one. wxWidgets knows nothing about blocks and chunks. The problem can be related to aMule here, though it could be a leak in wxWidgets too.

Now I have understood that everyone limits the upload bandwith. It is possible that none of the developers has tried to run aMule without limiting it, not for many hours anyway. So, the bug may be very real, but only I noticed it because I was stupid enough not to limit the bandwith. :-)
Well, actually "hopelessone" had some similar problems, right.

Well, I have been stupid like this too in the past But you soon realize that without limits, any other network activities are impossible. But even then it is not supposed to eat your system RAM. I will do a test to keep it downloading without limits to see what happens.

[JuhaManninen]

Now aMule was running 3 days and night before dying. The upload limit affected, I guess.
The error is "Segmentation fault" but I would say the problem is not my hardware. It has been extremely reliable all the time.
Here is the output from gdb, I don't know if it helps.

[New Thread 0xac01db90 (LWP 10570)]
[Thread 0xac01db90 (LWP 10570) exited]
Error on count 2 tag 0
Unknown port receiving an UDP packet! Ignoring         <--  these were some time earlier

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6c676d0 (LWP 8114)]
0xe4e4e4ff in ?? ()
(gdb) bt
#0  0xe4e4e4ff in ?? ()
#1  0xb7b57f94 in _GSocket_GDK_Input (data=0xa5a36e0, source=119, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:36
#2  0xb7183c4f in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#3  0x0a5a36e0 in ?? ()
#4  0x00000077 in ?? ()
#5  0xb7068d2d in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb4e00590 in ?? ()
#7  0x00000004 in ?? ()
#8  0xb70395d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0xb703c972 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0x0895ec00 in ?? ()
#11 0x00000000 in ?? ()
(gdb) bt full
#0  0xe4e4e4ff in ?? ()
No symbol table info available.
#1  0xb7b57f94 in _GSocket_GDK_Input (data=0xa5a36e0, source=119, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:36
        socket = (GSocket *) 0xa5a36e0
#2  0xb7183c4f in ?? () from /usr/lib/libgdk-x11-2.0.so.0
No symbol table info available.
#3  0x0a5a36e0 in ?? ()
No symbol table info available.
#4  0x00000077 in ?? ()
No symbol table info available.
#5  0xb7068d2d in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#6  0xb4e00590 in ?? ()
No symbol table info available.
#7  0x00000004 in ?? ()
No symbol table info available.
#8  0xb70395d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#9  0xb703c972 in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#10 0x0895ec00 in ?? ()
No symbol table info available.
#11 0x00000000 in ?? ()
No symbol table info available.
(gdb) thread apply all bt

Thread 4 (Thread 0xb57b1b90 (LWP 8122)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7f5d7ec in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb78f8cd1 in wxConditionInternal::WaitTimeout (this=0x8993278, milliseconds=97) at ./src/unix/threadpsx.cpp:405
#3  0xb78f8db6 in wxCondition::WaitTimeout (this=0x89931e4, milliseconds=97) at ./include/wx/thrimpl.cpp:256
#4  0xb78f9bdb in wxSemaphoreInternal::WaitTimeout (this=0x89931e0, milliseconds=97) at ./src/unix/threadpsx.cpp:552
#5  0xb78f9cc4 in wxSemaphore::WaitTimeout (this=0x89aff48, milliseconds=97) at ./include/wx/thrimpl.cpp:320
#6  0x0835e576 in CTimerThread::Entry (this=0x89aff28) at Timer.cpp:63
#7  0xb78faf94 in wxThreadInternal::PthreadStart (thread=0x89aff28) at ./src/unix/threadpsx.cpp:766
#8  0xb78fb0ff in wxPthreadStart (ptr=0x89aff28) at ./src/unix/threadpsx.cpp:718
#9  0xb7f59192 in start_thread () from /lib/libpthread.so.0
#10 0xb762702e in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb67feb90 (LWP 8120)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7f60846 in nanosleep () from /lib/libpthread.so.0
#2  0xb7904dbd in wxMicroSleep (microseconds=29000) at ./src/unix/utilsunx.cpp:191
#3  0xb7904de7 in wxMilliSleep (milliseconds=29) at ./src/unix/utilsunx.cpp:212
#4  0xb78f8969 in wxThread::Sleep (milliseconds=29) at ./src/unix/threadpsx.cpp:986
#5  0x081be20b in UploadBandwidthThrottler::Entry (this=0x905c608) at UploadBandwidthThrottler.cpp:324
#6  0xb78faf94 in wxThreadInternal::PthreadStart (thread=0x905c608) at ./src/unix/threadpsx.cpp:766
#7  0xb78fb0ff in wxPthreadStart (ptr=0x905c608) at ./src/unix/threadpsx.cpp:718
#8  0xb7f59192 in start_thread () from /lib/libpthread.so.0
#9  0xb762702e in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb6c676d0 (LWP 8114)):
#0  0xe4e4e4ff in ?? ()
#1  0xb7b57f94 in _GSocket_GDK_Input (data=0xa5a36e0, source=119, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:36
#2  0xb7183c4f in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#3  0x0a5a36e0 in ?? ()
#4  0x00000077 in ?? ()
#5  0xb7068d2d in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb4e00590 in ?? ()
#7  0x00000004 in ?? ()
#8  0xb70395d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0xb703c972 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0x0895ec00 in ?? ()
#11 0x00000000 in ?? ()
(gdb)

[JuhaManninen]

1. its in the preferences>>files>>"Try to transfer full chunks to all uploads" <<-make sure it's enabled..

2.  preferences>>connection>>slot allocation

have a read of this http://ubuntuforums.org/showthread.php?t=526975&highlight=amule+tweak

hope helps..

Looks like "Try to transfer full chunks to all uploads" setting has been enabled all the time.

Thanks for the link. My "Slot allocation" limit setting is 2 which seems quite low. I should have the default settings everywhere but I may have changed something by accident. My ADSL line speed is 1 Mbit (128 MB).
My TCP port is 4662 and UDP port 4672, and I have opened them in Suse's firewall settings.

I am still thinking if there is some Suse related thing causing the problem. A different version of some library or something. Otherwise Suse is very good, not many bugs really.

Juha

[phoenix]

 JuhaManninen,

I use Suse 10.2 here, but all aMule related suff is hand compiled. By all I mean wxWidgets, libUPnP and cryptopp.

Segmentation fault is not likely to be a hardware error. I have had the same error you have just reported some times in the past, seems pretty random, but by not limiting uploads you might have indeed rised the probability of happening.

Code: [Select]

#1  0xb7b57f94 in _GSocket_GDK_Input (data=0xa5a36e0, source=119, condition=GDK_INPUT_WRITE) at ./src/gtk/gsockgtk.cpp:36This is deep inside wxWidgets. Even with a debug version I was not able to get much information on this.