Print

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

[guest]

Another backtrace:

Code: [Select]

Current version is: aMule 2.2.6 using wxGTK2 v2.8.11
Running on: Linux 2.6.35-24-generic i686

[2] ?? in amule[0x8080399]
[3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0x6c5896]
[4] ?? in [0xfe6400]
[5] __pthread_mutex_lock in /lib/libpthread.so.0[0x84a3bd]
[6] ?? in /lib/libglib-2.0.so.0[0x4d1e118]
[7] g_io_add_watch_full in /lib/libglib-2.0.so.0[0x4d159b0]
[8] gdk_input_add_full in /usr/lib/libgdk-x11-2.0.so.0[0x780d71]
[9] gdk_input_add in /usr/lib/libgdk-x11-2.0.so.0[0x780dbe]
[10] GSocketGUIFunctionsTableConcrete::Install_Callback(GSocket*, GSocketEvent) in /usr/lib/libwx_gtk2u_core-2.8.so.0[0x37df85]
[11] GSocket::Enable(GSocketEvent) in /usr/lib/libwx_baseu_net-2.8.so.0[0x82716d]
[12] GSocket::Write(char const*, int) in /usr/lib/libwx_baseu_net-2.8.so.0[0x82853a]
[13] wxSocketBase::_Write(void const*, unsigned int) in /usr/lib/libwx_baseu_net-2.8.so.0[0x8237d6]
[14] wxSocketBase::Write(void const*, unsigned int) in /usr/lib/libwx_baseu_net-2.8.so.0[0x823947]
[15] ?? in amule[0x81fbb6d]
[16] ?? in amule[0x80de56c]
[17] ?? in amule[0x80dd621]
[18] ?? in amule[0x80b1424]
[19] ?? in amule[0x8120d23]
[20] wxThreadInternal::PthreadStart(wxThread*) in /usr/lib/libwx_baseu-2.8.so.0[0x6bffb8]
[21] wxPthreadStart in /usr/lib/libwx_baseu-2.8.so.0[0x6c001d]
[22] ?? in /lib/libpthread.so.0[0x847cc9]
[23] clone in /lib/libc.so.6[0xee669e]

Crashes in Ubuntu systematilly. The solution does not limit download is good temporarily, but it is only provisional. My system is updated to the latest versions of official ubuntu's kernel. Sorry for my english, i'am spanish. Thanks 

[RRM]

Huh?
Your amule version is 2.2.6...

[btkaos]

I guest, did this crash occur when limiting download?

[guest]

I'm the guest witht eh amd x64 system. Ran amule overnight no problems crashing while limits turned off. Whereas everytime I crashed before I had limits enabled. I also did notice that the download speed was an issue as it throttled itself to less than the upload speed. If I enabled some limits the ratio was much better. Would the changes that occured in the kernal be affecting the socket/connection handling of amule?

[guest]

SVN 10429 on amd x64 ubuntu -24 kernal crashes if download limits are enabled. If they are disabled but enabled at a later stage it crashes quite quickly.

[Stu Redman]

Ok, fits into the picture. Now all we need is a solution. 

[GuitarPlayer]

Hi all,
I've been having the same problem.I'm very glad I found this post because setting the download limit to 0 has solved the issue for me. I thought it was the 2.2.6 aMule version from the RPMfusion repos, but I compiled SVN 10443 with all the options and had the same problem. 
aMule has been running crash free for 11 hours now which is about 10.5 hours longer than it has ever been running recently.
Just for info, my o/s is Fedora 14 (x86_64) , kernel 2.6.35.10-74. I saw somewhere in the posts here that this issue may have something to do with glib, so its version is: Glib2 2.26.0-2.fc14.
Also, I saw a question posed as to the timing of the RAM and swap space getting used up. In my case, everything would be running very stable, and then all of a sudden, the RAM filled, and then swap space started filling very fast (within a second or two) which caused system lockup.
I hope that this info helps track the issue. Feel free to contact me for help or more info. I compiled with debug so I could do testing if someone tells me what they want.
best regards 

[^marcell^]

Setting the download limit to 0 doesn't really solve the issue on my side. Instead it seems to limit the probability of occuring. Ever since the OOM issue arised I kept the download limit at 0 and even so it still crashes from time to time. On much fewer occasions, but still it does.

[btkaos]

Setting the download limit to 0 doesn't really solve the issue on my side. Instead it seems to limit the probability of occuring. Ever since the OOM issue arised I kept the download limit at 0 and even so it still crashes from time to time. On much fewer occasions, but still it does.

AFAICT it could make sense, but I couldn't reproduce this exact crash with DL set to 0. Does the backtrace look the same?

^marcell^ what kind of load is in your eMule? Number of files, network capacity, average and maximum dl speed, upload speed, number of sources, etc.. Knowing that would be useful as then I'd try to replicate the load and the crash with DL set to 0.

Of course you may send me the date by PM if you are not confortable.

[Stu Redman]

It probably also depends on the behavior of the other clients, like if they will close the connection if you download too slow or not. Which makes it quite random.

[btkaos]

I've made a lot of testing and I never had trouble when the dl limit was set to 0, but it seems marcell has a new bug.

IMHO is very important to understand if dl limiting is the key factor for the bug.

[^marcell^]

How do I obtian a backtrace if the OS is killing aMule, because it allocates too much memory?
I am going to start aMule right now (using gdb) and hope you can give me an answer so I can post more information.

[btkaos]

How do I obtian a backtrace if the OS is killing aMule, because it allocates too much memory?

marcell see the other thread (in amule bugs), there my script is posted (it would be good to read it all)

Anyways what I do is to monitor amule and when it passes 3Gb of memory I fire up gdb, then I get all the backtraces of amule eating memory that I want.

[btkaos]

Hi all, Kry posted a wx patch in the other thread (look in bugs forum) which seems to solve the issue for me.

Just a rebuilt of wx is needed, I encourage you to try it.

[Olhado]

It seems that the patch solved the issue for me too  I have three very popular files in my download queue, my download limit is set to 10 kb/s, and aMule has been running all day with zero problems.