aMule Forum
English => en_Bugs => Topic started by: myth on August 06, 2009, 01:08:44 PM
-
This morning when I called aMule back from the tray bar the window didn't react to any action and was blocked.
aMule used all 3 GB of ram and filled also 1.7 GB of swap!
After this it closed itself, but I don't know for what it was...and I can't reproduce it!
Nothing in log...so I think I'm not really helpfull...(<-- new word :D )
I'm using SVN build 9748...
Stu: that typo was bugging me...
-
What's your average upload speed?
RRM always has this problem (http://forum.amule.org/index.php?topic=16035.msg90237#msg90237), but he's uploading at ethernet speed. Looks like something is breaking and memleaking at such speeds. Too bad I can't reproduce it. :)
-
No....I'm dreaming of a connection like this...I'll never have more than my 2000 Kbit/s Down || 340 Kbit/s Up...(~250 KB/s || 40 KB/s)
-
Another time the same thing :(
Nothing in log...
-
Could you possibly run amule with the Valgrind heap profiler (http://valgrind.org/docs/manual/ms-manual.html)? You need a build with debug symbols to get a useful output.
-
I'll see, when I have the time to do it ;)
-
I'll be on vacation next week anyway. :D
-
Yeah, no stress! ...and good vacation!
Until this problem doesn't happen much times, I have no big problems with it!
-
I didn't still make the debug build...but...!
I disabled Swap because I don't need it, having 3 GB of ram...now a strange thing happened: The same procedure, but Thunderbird and JDownloader closed! Maybe for aMule taking all ram?
-
Probably. :)
-
I made a debug build now, and started with GDB...maybe it takes some days...like before... :)
-
You need to start it with valgrind, GDB won't help.
-
Sry, can't run this thing with valgrind....it always puts my Core2Duo at very high usage...and aMule isn't really reactive... :/
-
Another Hang-up.
When I went to tty2 to go to kill aMule, I got this on console:
[583704.378443] Out of memory: kill process 2964 (amule) score 230834 or a child
[583704.378519] Killed process 2964 (amule)
-
What's the size of your key_index.dat and src_index.dat ?
-
They are:
key_index.dat -> 2,037,743 Bytes
src_index.dat -> 451,117 Bytes
-
Looks ordinary, no sign of cache poisoning. (Though your app crashes before it can rewrite it probably, so I'm not ready to rule that out yet.)
For the fun of it - stop, delete your preferencesKad.dat, restart. It will take you to a different place in the Kad network. Maybe you have hit a hot spot there.
-
Until now it ran fine for 3 days without taskbar (minimized), and then same thing again, so now I'm installing valgrind, and I'll let it run until it crahes ;)
-
Wtf, running with valgrind and debug build...over 3 days now, and it won't crash :S
-
A watched pot never boils. ;D
-
Now it boiled! But i had no output file from valgrind --tool=massif amule !! :(
So i thought: start it just 1 time with gdb and it doesn't start with this error:
Breakpoint 2 at 0x6a1402: file amule-gui.cpp, line 94.
Starting program: /usr/local/bin/amule
[Thread debugging using libthread_db enabled]
[New Thread 0x7f179d5807e0 (LWP 8652)]
[Switching to Thread 0x7f179d5807e0 (LWP 8652)]
main (argc=1, argv=0x7fffa55bba58) at amule-gui.cpp:94
94 IMPLEMENT_APP(CamuleGuiApp)
???
EDIT: Starting it normally works!
-
But i had no output file from valgrind --tool=massif amule !! :(
Really? It should have writen a log named like the process number. Not there?
So i thought: start it just 1 time with gdb and it doesn't start with this error:
Did you type run ?
-
No, really no output file :(
For GDB...well i typed start...and there I became the error...
-
Some news:
Before aMule crashed he took 350 MB of RAM...and now after 12 hours it takes 100 MB, slowly increasing.
Could this help?
-
Not really. :(
-
Shice...i'll give another try with valgrind...
-
Try to exit it after a few minutes and see if it writes a memlog. No use running it for days if it doesn't.
-
Here's a brief description of what happened to me two days earlier (this is not helping, but proving that something is not right):
- started my notebook the morning and started aMule to download some things (ed2k + kad connected)
- went to work
- came back from work
- black screen on the notebook, because of power-saving function of xubuntu turned screen off
- so... moved the mouse
- notebook starts reading from hard disk like crazy and doesn't really respond
- one minute later desktop is visible and applet showing both RAM and SWAP are full
- one minute later xubuntu kills aMule because "Out of Memory" was detected
- memory is freed and notebook is responding normally again
???
EDIT: Just remembered some important detail: while I was at work two 350 MB files got completed.
The notebook has 512 MB RAM.
-
I don't know why valgrind doesn't save any output file :(
But here I have the last lines from the terminal: http://pastebin.me/6c290a67e494edc0e31330ffa1101e33
-
The so-called "errors": "Use of uninitialised value of size 8" and "Conditional jump or move depends on uninitialised value(s)" relating to CryptoPP are normal.
Assuming that console output was generated after aMule was killed (and not after a clean exit) reported memory leaks are also normal (aMule didn't have a chance to clean up).
Apart from that I see nothing interesting at first glance. Someone with sharper eyes or more thorough look may find something, but I disbelieve.
-
Shit :(
With what command should I fire up valgrind + amule? In any way I should also have the damn output file no? (He should save it in the directory I am when typing the command, right?)
-
valgrind --tool=massif amule
Don't tray it with more than say 20 downloads, or it will freeze at 100%CPU. :D
-
Usually I have NO downloads... ;)
I'll try another time right now!
-
Maybe something not relevant, but I post it!
2009-09-14 08:23:37: SafeFile.cpp(475): Invalid Kad tag; type=0x02 name=
2009-09-14 16:04:03: SafeFile.cpp(475): Invalid Kad tag; type=0x22 name=
2009-09-14 22:19:32: SharedFileList.cpp(325): Adding file /mnt/storage/mule/Temp/001.part.met to shares
2009-09-14 22:19:32: SharedFileList.cpp(325): Adding file /mnt/storage/mule/Temp/002.part.met to shares
--------------------------------------------------------------------------------
A fatal error has occurred and aMule has crashed.
Please assist us in fixing this problem by posting the backtrace below in our
'aMule Crashes' forum and include as much information as possible regarding the
circumstances of this crash. The forum is located here:
http://forum.amule.org/index.php?board=67.0
If possible, please try to generate a real backtrace of this crash:
http://wiki.amule.org/index.php/Backtraces
----------------------------=| BACKTRACE FOLLOWS: |=----------------------------
Current version is: aMule SVN using wxGTK2 v2.8.10 (Snapshot: rev. 9786)
Running on: Linux 2.6.28-15-generic x86_64
[2] ?? in amule [0x45b873]
[3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0x6e86c3c]
[4] ?? in /lib/libpthread.so.0 [0x4e38080]
--------------------------------------------------------------------------------
==26737==
Killed
This is from valgrind console...I closed aMule...
AND: Still no output file!!!
-
Did it crash right after startup or later ?
And do you get a memtrace if you let it start up and then just exit it normally?
-
Wait!!! I have a memtrace!
http://rapidshare.com/files/280247222/massif.out.26737
I hope it can help :P
-
I'm getting an idea...
What verbose debug output options do you have enabled? Disable them. Looks like the list control for the log messages is running crazy. ;D
Maybe we should limit that baby at some sensible maximum. Data is still in the log file.
-
I guess this is not the same problem than RRM's
myth, would you care to post:
- how long does amule take to eat all the memory. I mean, does it suddenly go crazy or it keeps growing slowly.
- you libx11, libx11-xcb and libxcb version.
Regards.
-
Ok, debug log activated, but all options unticked ;)
Now, after 23 hours aMule is at 200 MB...but this is just normal, with 4 downloads with many sources!
The problem with the full RAM usage happens as following:
Sometimes when I call back aMule from tray, the aMule GUI freezes, and RAM increases fast until maximum (or better until I kill it!)<-- Even killing isn't easy! sudo top, then from there usually it gets killed.
The last logfile.bak has 80 MB of size... ::)
-
Looks like the list control for the log messages is running crazy. ;D
The last logfile.bak has 80 MB of size... ::)
Than that shouldn't be the cause.
Maybe we should limit that baby at some sensible maximum. Data is still in the log file.
Already on my mind. After a long debug run I just said to myself "Oh, my God! It keeps the log in memory ?!?!?!" So, yes, totally agreed.
-
The last logfile.bak has 80 MB of size... ::)
With all options unticked? :o
Than that shouldn't be the cause.
I'm not ready to rule that out. It's iconized and silently growing. Then it suddenly has to be displayed. Maybe in that moment the huge amount of data gets transferred from wx to GTK and something goes bugshit there.
-
Maybe. With an 80MB log file it shouldn't be more than ~320MB although I don't know GTK internals.
-
More than storage, it might be the communication and signals.
-
The last logfile.bak has 80 MB of size... ::)
With all options unticked? :o
No, there it was with some options ticked ;)
Now I've unticked them all! :D
-
OK. So let's see if that fixes it.
-
Nope...and also with non-debug-build it crashes... :/
But I have a suspect: Maybe it happens only when I call back aMule from tray (or taskbar), when in the time it was minimized, the (Kad) IP changed...could this be?
-
There shouldn't be any relation of the two. ("shouldn't be" is not necessarily equal to "there isn't" - but I don't know how could a Kad IP change influence a GUI restore event)
-
but I don't know how could a Kad IP change influence a GUI restore event
I also don't believe it ;)
Was my information good enought to find the bug?
-
I'm afraid not. :(
-
Well...I'm running it again with valgrind. For now i can provide my ./configure and make output:
./configure (http://pastebin.org/25902)
make (http://pastebin.org/25906)
EDIT: Here also some line from the terminal:
http://pastebin.org/25919 (http://pastebin.org/25919)
Look at the last lines!
-
You should run the massif heap profile, not the error checker.
And yeah, CryptoPP is buggy. We all know that. :(
-
It crashed!
Here is the Massif Output file: RS (1,1 MiB) (http://rapidshare.com/files/286582617/massif.out.9210)
I hope it helps!
-
Yes and no... :-\
#-----------
snapshot=84
#-----------
time=9887090961847
mem_heap_B=244515253
mem_heap_extra_B=84623107
mem_stacks_B=0
heap_tree=peak
n7: 244515253 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n2: 136686880 0xBB1FCD8: _XSend (in /usr/lib/libX11.so.6.2.0)
n2: 136686880 0xBB1FF1F: _XReply (in /usr/lib/libX11.so.6.2.0)
n1: 136686880 0xBAFD244: XGetWindowProperty (in /usr/lib/libX11.so.6.2.0)
n1: 136686880 0x8486730: (within /usr/lib/libgdk-x11-2.0.so.0.1600.1)
n1: 136686880 0x8486AE5: (within /usr/lib/libgdk-x11-2.0.so.0.1600.1)
n1: 136686880 0x8486F0C: (within /usr/lib/libgdk-x11-2.0.so.0.1600.1)
n1: 136686880 0x9F51208: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.2000.1)
n1: 136686880 0x9F548DE: (within /usr/lib/libglib-2.0.so.0.2000.1)
n1: 136686880 0x9F54DAB: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.2000.1)
n1: 136686880 0x7F6FBC5: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1600.1)
n2: 136686880 0x672AA26: wxEventLoop::Run() (in /usr/lib/libwx_gtk2u_core-2.8.so.0.6.0)
n1: 136686880 0x67B08B9: wxAppBase::MainLoop() (in /usr/lib/libwx_gtk2u_core-2.8.so.0.6.0)
n1: 136686880 0x6E2755B: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.8.so.0.6.0)
n0: 136686880 0x6A27C5: main (amule-gui.cpp:94)
n0: 0 in 1 place, below massif's threshold (01.00%)
n0: 0 in 5 places, all below massif's threshold (01.00%)
n0: 0 in 2 places, all below massif's threshold (01.00%)
n2: 50920296 0x6E47D76: wxStringBase::Alloc(unsigned long) (in /usr/lib/libwx_baseu-2.8.so.0.6.0)
n2: 50843096 0x6E47F39: wxStringBase::ConcatSelf(unsigned long, wchar_t const*, unsigned long) (in /usr/lib/libwx_baseu-2.8.so.0.6.0)
n2: 50687288 0x6E49A31: wxString::wxString(char const*, wxMBConv const&, unsigned long) (in /usr/lib/libwx_baseu-2.8.so.0.6.0)
n2: 50673976 0x7FA758: CFileDataIO::ReadOnlyString(bool, unsigned short) const (SafeFile.cpp:254)
n3: 43802176 0x7F88E7: CFileDataIO::ReadString(bool, unsigned char, bool) const (SafeFile.cpp:226)
n2: 22940920 0x7F9773: CFileDataIO::ReadTag(bool) const (SafeFile.cpp:434)
n1: 21646560 0x654012: Kademlia::CKademliaUDPListener::Process2PublishKeyRequest(unsigned char const*, unsigned int, unsigned int, unsigned short, Kademlia::CKadUDPKey const&) (KademliaUDPListener.cpp:1579)
n1: 21646560 0x663629: Kademlia::CKademliaUDPListener::ProcessPacket(unsigned char const*, unsigned int, unsigned int, unsigned short, bool, Kademlia::CKadUDPKey const&) (KademliaUDPListener.cpp:352)
n2: 21646560 0x624A47: Kademlia::CKademlia::ProcessPacket(unsigned char const*, unsigned int, unsigned int, unsigned short, bool, Kademlia::CKadUDPKey const&) (Kademlia.cpp:292)
This first block is expanding rapidly, probably until memory exhaustion. It's all in GDK/X, and probably triggered by your restoring it from the icon. But there is no aMule code directly involved, so I can't say where to put my finger on. :(
Should we start debugging X now? Are there any updates available you haven't yet?
-
Shit :/
WxWidgets have to do something with it?
It seems they are installed correctly.
To be shure I'm just trying to download and install 2.9.0 version. (now I have 2.8.10)
EDIT: I won't change the wxwidgets right now...I don't feel like it now :P
-
You might run into lots of new & interesting problems with 2.9 ... :-\
I have no idea if it's wx, GTK or X11. I don't know how they work together. All I can say is that XGetWindowProperty allocates memory for its return value. So it's obviously called in an infinite loop until memory is exhausted. I'd guess it's a GTK problem. Of course the complex tray icon code might also be related in some way. Can you just disable the tray icon?
-
OK, I disabled tray icon right now ;)
-
Strange but nice thing: I installed Ubuntu Linux 9.10 (2.6.31-14-generic) amd64, and until now I didn't encounter the problem any more! :)
-
Hopefully it was just aMule triggering a bug in another library which has already been fixed. Though it would be interesting to know...