aMule Forum
English => aMule crashes => Topic started by: cunha17 on November 16, 2010, 11:34:45 AM
-
-> OS
GNU/Linux - Fedora release 12 (Constantine) - Last update
kernel 2.6.32.23-170.fc12.x86_64
-> aMule version
amule-2.2.6-1.fc12.x86_64
-> Other things:
- Platform : 64 bits
- I tried to keep amule (GUI) running yesterday, but randomly it eats all memory and swap (I could verify this and had to kill emule myself because it had eaten 3.5GB RAM), then, I suspect, the OS kills it. This time, it crashed and the crash message is quoted below.
- This problem appeared recently, I can't tell if it was after the last FC12 update...
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 2.2.6 using wxGTK2 v2.8.10
Running on: Linux 2.6.32.23-170.fc12.x86_64 x86_64
[2] ?? in amule[0x443f14]
[3] wxFatalSignalHandler in /usr/lib64/libwx_baseu-2.8.so.0[0x316d4ebaac]
[4] ?? in /lib64/libpthread.so.0[0x316280f210]
[5] pthread_mutex_lock in /lib64/libpthread.so.0[0x3162808f00]
[6] ?? in /lib64/libglib-2.0.so.0[0x3164838f67]
[7] g_source_remove in /lib64/libglib-2.0.so.0[0x316483b49e]
[8] GSocketGUIFunctionsTableConcrete::Uninstall_Callback(GSocket*, GSocketEvent) in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x3171be8d86]
[9] GSocket::Detected_Write() in /usr/lib64/libwx_baseu_net-2.8.so.0[0x316e223f77]
[10] ?? in /usr/lib64/libgdk-x11-2.0.so.0[0x316fe2450f]
[11] g_main_context_dispatch in /lib64/libglib-2.0.so.0[0x316483923e]
[12] ?? in /lib64/libglib-2.0.so.0[0x316483cc28]
[13] g_main_loop_run in /lib64/libglib-2.0.so.0[0x316483d075]
[14] gtk_main in /usr/lib64/libgtk-x11-2.0.so.0[0x316f34beb7]
[15] wxEventLoop::Run() in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x3171be7ba8]
[16] wxAppBase::MainLoop() in /usr/lib64/libwx_gtk2u_core-2.8.so.0[0x3171c61a6b]
[17] wxEntry(int&, wchar_t**) in /usr/lib64/libwx_baseu-2.8.so.0[0x316d496385]
[18] ?? in amule[0x50e0c2]
[19] __libc_start_main in /lib64/libc.so.6[0x3161c1eb1d]
[20] ?? in amule[0x442f59]
--------------------------------------------------------------------------------
-
Reminds me of this: http://forum.amule.org/index.php?topic=18278.0
Do you have tray icon enabled? Do things improve when you disable it?
-
I have the same problem too. I'm running aMule version 2.2.6+debian0-8ubuntu1 on Kubuntu 10.10 (x64).
I noticed that the problem had begun when I upgraded the kernel to version 2.6.35-23. With kernel version 2.6.35.22 the problem have never appeared, and if I boot the pc with this old kernel, the problem continues not to appear.
PS: I also have the tray icon enabled.
-
Do things improve when you disable the tray icon?
-
I tried it, but aMule crashed the same.
And I'm a bit more unlucky than cunha17, because with aMule also the system crashes.
-
Hmm, I'd say when the system crashes it's the system's fault. And switching back the Kernel seems to solve it.
I'd try to compile the app yourself with current kernel and current runtime lib. Maybe this helps. I have no idea if your binary package is supposed to work in your OS at all. There is a description in the wiki.
-
In the last weeks I was trying to do many experiments to understand the problem (I recompiled the package, and then the SVN, then I tried to understand if the problem was related tho the notify icon as you suggested).
Reading the next topic (http://forum.amule.org/index.php?topic=18444.0 (http://forum.amule.org/index.php?topic=18444.0)), someone more expert than me tried more successful experiments.
But with the last kernel update (2.6.35-23.41) the problem seems to have disappeared.
-
Bad news. The last kernel is not the solution.
Maybe the problem disappeared for a period because I was doing few and small downloads.
-
The Ubuntu guys reported it works with Kernel 2.6.35-22.
Could you try to run it with Valgrind's memcheck ? Maybe that can give a hint what is leaking.
-
In this (long) period I made (holidays and then) many experiments. I tried to relate the application's crashes with some action of it or of mine. I did not have much success...
The greatest insuccess was Valgrind. aMule started with Valgrid runs very very slow! You can't make many tries with the interface, and most of all the downloads are quite absents (in addiction I received a low id). But in two occasions I was able to obtain something, but not very useful:
==3379== More than 10000000 total errors detected. I'm not reporting any more.
==3379== Final error counts will be inaccurate. Go fix your program!
==3379== Rerun with --error-limit=no to disable this cutoff. Note
==3379== that errors may occur in your program without prior warning from
==3379== Valgrind, because errors are no longer being displayed.
There was a huge number of these errors repeated:
==3379== Conditional jump or move depends on uninitialised value(s)
==3379== at 0x5895C67: CryptoPP::Integer::operator=(CryptoPP::Integer const&) (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x5898C2C: CryptoPP::Integer::Divide(CryptoPP::Integer&, CryptoPP::Integer&, CryptoPP::Integer const&, CryptoPP::Integer const&) (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x5898CAE: CryptoPP::Integer::Modulo(CryptoPP::Integer const&) const (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x58B3461: CryptoPP::CRT(CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&) (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x58B3850: CryptoPP::ModularRoot(CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&, CryptoPP::Integer const&) (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x58D8885: CryptoPP::InvertibleRSAFunction::CalculateInverse(CryptoPP::RandomNumberGenerator&, CryptoPP::Integer const&) const (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x49EC20: CryptoPP::TrapdoorFunctionInverse::CalculateRandomizedInverse(CryptoPP::RandomNumberGenerator&, CryptoPP::Integer const&) const (pubkey.h:95)
==3379== by 0x58C4318: CryptoPP::TF_SignerBase::SignAndRestart(CryptoPP::RandomNumberGenerator&, CryptoPP::PK_MessageAccumulator&, unsigned char*, bool) const (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x57ED1FA: CryptoPP::PK_Signer::SignMessage(CryptoPP::RandomNumberGenerator&, unsigned char const*, unsigned long, unsigned char*) const (in /usr/lib/libcrypto++.so.8.0.0)
==3379== by 0x499CEC: CClientCreditsList::CreateSignature(CClientCredits*, unsigned char*, unsigned char, unsigned int, unsigned char, void*) (ClientCreditsList.cpp:362)
==3379== by 0x4694ED: CUpDownClient::SendSignaturePacket() (BaseClient.cpp:2118)
==3379== by 0x46985A: CUpDownClient::ProcessPublicKeyPacket(unsigned char const*, unsigned int) (BaseClient.cpp:2154)
but the last error reported is this:
==3379== Conditional jump or move depends on uninitialised value(s)
==3379== at 0x5342E40: inflateReset2 (in /lib/libz.so.1.2.3.4)
==3379== by 0x5342F2F: inflateInit2_ (in /lib/libz.so.1.2.3.4)
==3379== by 0x533D648: uncompress (in /lib/libz.so.1.2.3.4)
==3379== by 0x792AA4: CPacket::UnPackPacket(unsigned int) (Packet.cpp:292)
==3379== by 0x5B34C6: CServerSocket::PacketReceived(CPacket*) (ServerSocket.cpp:665)
==3379== by 0x51DB1F: CEMSocket::OnReceive(int) (EMSocket.cpp:284)
==3379== by 0x5AF5A6: CServerSocket::OnReceive(wxSocketError) (ServerSocket.cpp:211)
==3379== by 0x5AEC9F: CServerSocketHandler::ServerSocketHandler(wxSocketEvent&) (ServerSocket.cpp:99)
==3379== by 0x6E5530F: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==3379== by 0x6E562D3: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==3379== by 0x6E563B6: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
==3379== by 0x6E5575F: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.8.so.0.7.0)
This is the last because then there was the limit, not last because in this moment aMule crashed. I never reached a crash vith Valgrind!
Then I tried Valgrind with the no-limit option, but, I don't know why, aMule freezed after showing its interface and before connecting to the networks.
So I tried to repeat or observe some behaviours that seemed to make aMule crash. I found no relations with the download limit, and with the number of files I was downloading. I tried to start aMule and leave it there without touching everything of the interface. For a moment I had thought the problem happened only if I had minimized at least one time the window, but then I observed this is not a fixed law. I had noticed that if I never have minimized the window, the application didn't crash filling the memory, but with a "normal" crash:
--------------------------------------------------------------------------------
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 compiled with wxGTK2 v2.8.11 (Snapshot: rev. 10424)
Running on: Linux 2.6.35-25-generic x86_64
[2] CamuleApp::OnFatalException() in amule.cpp:1020
[3] wxFatalSignalHandler in /usr/lib/libwx_baseu-2.8.so.0[0x7fda7c2a272c]
[4] ?? in /lib/libpthread.so.0[0x7fda7e242b40]
[5] pthread_mutex_lock in /lib/libpthread.so.0[0x7fda7e23c634]
[6] ?? in /lib/libglib-2.0.so.0[0x7fda78e1d04f]
[7] g_source_remove in /lib/libglib-2.0.so.0[0x7fda78e1f90e]
[8] GSocketGUIFunctionsTableConcrete::Uninstall_Callback(GSocket*, GSocketEvent) in /usr/lib/libwx_gtk2u_core-2.8.so.0[0x7fda7c90bc56]
[9] GSocket::Detected_Write() in /usr/lib/libwx_baseu_net-2.8.so.0[0x7fda7c52f5a7]
[10] ?? in /usr/lib/libgdk-x11-2.0.so.0[0x7fda7a9b499f]
[11] g_main_context_dispatch in /lib/libglib-2.0.so.0[0x7fda78e1d342]
[12] ?? in /lib/libglib-2.0.so.0[0x7fda78e212a8]
[13] g_main_loop_run in /lib/libglib-2.0.so.0[0x7fda78e217b5]
[14] gtk_main in /usr/lib/libgtk-x11-2.0.so.0[0x7fda7ad733e7]
[15] wxEventLoop::Run() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0x7fda7c90a578]
[16] wxAppBase::MainLoop() in /usr/lib/libwx_gtk2u_core-2.8.so.0[0x7fda7c98fb0b]
[17] wxEntry(int&, wchar_t**) in /usr/lib/libwx_baseu-2.8.so.0[0x7fda7c244695]
[18] main in amule-gui.cpp:93
[19] __libc_start_main in /lib/libc.so.6[0x7fda7b47fd8e]
[20] _start in :0
--------------------------------------------------------------------------------
Only one of my experiments had a full success. I'm sure the problem (both the types of crash) depends on the dimension of the files I'm downloading. I usually have files of 200-350 MB, and with these ones aMule never crashes (in this moment it has been running for more than 12 hours).
I reported all the tests I have done, knowing that someone was useless, but hoping that you could find something useful in them.
-
Thank you for you work!
We made some progress meanwhile. Problem is triggered by the download limit. Set download limit to zero (unlimited), and the problem goes away.
-
Hi Pinsy, as STU said we half-know the cause of that particular crash (corruption of glib's context).
Have a look at this thread, there's some more information there.
http://forum.amule.org/index.php?topic=18506.0