Print

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

[RRM]

RRM, you're learning fast.

Ehhrr, it took me 31 pages to learn a tiny fraction of what you know...
but thanks  

But beware, after getting used to the taste of bleeding-edge, you won't be able to go without it ... it's addictive

Yes   it tastes good!
...i want more...  

Rev. 9928 with the modified patch runs perfectly fine, Stu.

[GonoszTopi]

RRM, you're learning fast.

Ehhrr, it took me 31 pages to learn a tiny fraction of what you know...
but thanks 

It's just that we started earlier...

[Stu Redman]

Rev. 9928 with the modified patch runs perfectly fine, Stu.

Very good. Keep it running for a while, then I'll commit it.

[RRM]

Keep it running for a while, then I'll commit it.

Still running...

[RRM]

... and running....

Nice, its running so fast that i had to re-fuel; i ran out of downloads,
so that im now downloading some popular files that i already have, just for the sake of the test...

[Stu Redman]

OK. I'll commit this new version then. 

[btkaos]

Sorry for reviving this topic, but so far RRM backtraces are the same than the ones I got in the recent thread:

http://forum.amule.org/index.php?topic=18506.0

And Kry fixed with a wx patch. Just see RRM's backtrace:

Code: [Select]

#0  0xb8079430 in __kernel_vsyscall ()
#1  0xb72588a0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb725a268 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb747b655 in __cxxabiv1::__terminate (handler=0x808a378 <abort@plt>)  at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:43
#4  0xb747b692 in std::terminate ()  at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:53
#5  0xb747b7ca in __cxa_throw (obj=0xb74aaaf0, tinfo=0x86e5a6c, dest=0xb747bd00 <~bad_alloc>)  at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:76
#6  0xb747be23 in operator new (sz=24) at ../../../../src/libstdc++-v3/libsupc++/new_op.cc:63
#7  0xb7560556 in wxObjectList::CreateNode (this=0x8ef76f8, prev=0x9b222b0, next=0x0, data=0x86e80c0, key=@0xb7660750) at ../include/wx/list.h:1178
#8  0xb7575759 in wxListBase::Append (this=0x8ef76f8, object=0x86e80c0) at ../src/common/list.cpp:244
#9  0xb75ddc26 in wxEvtHandler::AddPendingEvent (this=0x86e80c0,  event=@0xbfa784a0) at ../include/wx/list.h:1178
#10 0xb7681d58 in wxSocketBase::OnRequest (this=0x9b8fa90,  notification=wxSOCKET_OUTPUT) at ../src/common/socket.cpp:1006
#11 0xb7681e54 in wx_socket_callback (notification=GSOCK_OUTPUT,  cdata=0x9b8fa90 "\b-M\b") at ../src/common/socket.cpp:942
#12 0xb76866bb in GSocket::Detected_Write (this=0x9a49538)  at ../src/unix/gsocket.cpp:1836
#13 0xb77d0be7 in _GSocket_GDK_Input (data=0x9a49538, source=73,  condition=GDK_INPUT_WRITE) at ../src/gtk/gsockgtk.cpp:36
#14 0xb6e194af in gdk_io_invoke (source=0xb57303c0,  condition=<value optimized out>, data=0xb5731150)  at /build/buildd/gtk+2.0-2.14.4/gdk/gdkevents.c:1013
#15 0xb6bb771d in g_io_unix_dispatch (source=0xb572faa0,  callback=0xb6e19450 <gdk_io_invoke>, user_data=0xb5731150)   at /build/buildd/glib2.0-2.18.2/glib/giounix.c:162
#16 0xb6b80718 in IA__g_main_context_dispatch (context=0x8ecf918)  at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2144
#17 0xb6b83dc3 in g_main_context_iterate (context=0x8ecf918, block=1,  dispatch=1, self=0x8ed0ec0)    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2778
#18 0xb6b842e2 in IA__g_main_loop_run (loop=0x919d610)    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
#19 0xb6fb23a9 in IA__gtk_main ()    at /build/buildd/gtk+2.0-2.14.4/gtk/gtkmain.c:1200
#20 0xb77cf10b in wxEventLoop::Run (this=0x96fbc68)    at ../src/gtk/evtloop.cpp:76
#21 0xb78733dc in wxAppBase::MainLoop (this=0x8ecf7d0)   at ../src/common/appcmn.cpp:312
#22 0xb7873131 in wxAppBase::OnRun (this=0x6) at ../src/common/appcmn.cpp:367
#23 0xb75683fa in wxEntry (argc=@0xb76606cc, argv=0x8ebde38)   at ../src/common/init.cpp:460
#24 0xb75684b7 in wxEntry (argc=@0xbfa78810, argv=0xbfa78894)    at ../src/common/init.cpp:472
#25 0x082ac21d in main (argc=Cannot access memory at address 0x19eb) at ../../src/amule-gui.cpp:95

Same thing is happening, corruption of glib's context leads to an infinite number of events fixed.

I'm posting this because I was never very confortable with the patch in this thread, as I couldn't understand how it fixed the issue. Maybe in view of the new understanding of the problem we should reconsider the original patch. How is your amule doing RRM?

Do you remember setting some donwload limits? (I guess upload could cause the same problem, but much harder to achieve)

Regards,
BTK

[btkaos]

More relation to current bug:

Even if uploading to only 50 clients simultaneously, aMule will crash within 3 days
if uploading to only 65 clients simultaneously, aMule will crash within 2 days
if uploading to 100 clients simultaneously, aMule will crash within 1 day
if uploading to 200 clients simultaneously, aMule will usually crash within 3 hours (sometimes much sooner)

Fully makes sense wrt the download situation. When you have very slow download limit, lots of clients will connect, this is the exact moment the crash will happen.

So it is the same to simultaneously download from a lot of sources than to upload.

A characteristic of the crashes is that the build of VSZ starts very slowly,
and accelerates exponentially as VSZ increases.

Agrees with current bug.

Maybe the STU changes the load and timing somehow, needing more upload clients in order to trigger the bug, and RRM did never reach the critical limit anymore.

[Stu Redman]

Should be easy to verify.
RRM could you
- remove my patch and see if the crashes return
- then see if the wx patch fixes the problem

[RRM]

Hi Bill, great to see you again in this old thread;

I'm posting this because I was never very confortable with the patch in this thread, as I couldn't understand how it fixed the issue. Maybe in view of the new understanding of the problem we should reconsider the original patch. How is your amule doing RRM?

Absolutely perfect:
I never had a single crash since, while the mule is running 24/7,
uploading 3 MB/s almost constantly,
and using various SVN versions.

Do you remember setting some donwload limits? (I guess upload could cause the same problem, but much harder to achieve)

Yes, i did that at some point in this thread, for a short period, but as that didnt help, i went back to setting no limits,
and the crashes kept on coming, until Stu's last patch.
Since half a year my download and upload limits are both set to 5 MB/s.
(I dont know why i did that, and i didnt make any difference)

Should be easy to verify.
RRM could you
- remove my patch and see if the crashes return

Okay
So, on line 531 in the EMSocket.cpp
, i have to replace this:

Code: [Select]

if(byConnected == ES_CONNECTED && IsEncryptionLayerReady() && (!m_bBusy || onlyAllowedToSendControlPacket)) {

by this (as it used to be):

Code: [Select]

if(byConnected == ES_CONNECTED && IsEncryptionLayerReady() && !m_bBusy) {

Correct?

- then see if the wx patch fixes the problem

Ok, Kry's socket_mutex_fix.patch
containing patches for:
src/gtk/gsockgtk.cpp
src/unix/gsocket.cpp
include/wx/unix/gsockunx.h

As there is no gsockgtk.cpp file in my system, I just need to use the patch for gsockunx.h, right?
So, in the gsockunx.h, i replace:

Code: [Select]

  char *m_gui_dependent;

};

#ifdef __cplusplusby this:

Code: [Select]

  char *m_gui_dependent;
 
+#if wxUSE_THREADS
+
+  // Implemented in some platforms only for now
+  void LockData();
+  void UnlockData();
+
+  pthread_mutex_t m_thread_mutex;
+
+#endif
 };
 
 #ifdef __cplusplus

recompile the entire wxWidgets after patching.

Im sorry, i failed to find in forums how to recompile wxWidgets,
could anyone please explain how to do this?

[RRM]

Maybe i should first try limiting download and upload substantially,
by setting a 500 kB/s limit for example?
(as the limit set now is 5MB/s, which is no actual limit, as my uploadcapacity is just over 3 MB/s
and i dont download)
Or doesnt that make sense?

[btkaos]

RRM in order to recompile wxWidgets do the following:

Code: [Select]

$ cd
$ mkdir temp-amule
$ cd temp-amule
$ wget http://downloads.sourceforge.net/project/wxwindows/2.8.11/wxWidgets-2.8.11.tar.gz
$ tar xvfz wxWidgets-2.8.11.tar.gz
$ cd wxWidgets-2.8.11
save kry patch in that folder, let's say it is called kry.patch
$ cat kry.patch | patch -p1
$ ./configure --prefix=~/temp-amule/build/ --enable-debug
$ make install

After that I guess you don't need to recompile amule, just run it like

Code: [Select]

$ LD_LIBRARY_PATH=~/temp-amule/build/lib amule
You may verify it is using the new lib with

Code: [Select]

$ LD_LIBRARY_PATH=~/temp-amule/build/lib ldd amule

Regards,
BTK

[RRM]

Thank you, Bill.

[btkaos]

Thank you, Bill.

Thank you for testing. You should perform two tests: One with stock amule (svn) and stock wx 2.8.11 and the other with patched wx.

You can do this simple by using the LD_LIBRARY_PATH variable.

For safety, that is to say, to know you are testing the right libs, perform the ldd tests first and then post the output here.

Code: [Select]

$ ldd amule #(post the output)
$ LD_LIBRARY_PATH=~/temp-amule/build/lib ldd amule
If ~ doesn't work substitute it for /home/rrm or whatever directory you'd like.

[RRM]

You should perform two tests: One with stock amule (svn) and stock wx 2.8.11 and the other with patched wx.

Ehr, stock SVN is what i have been using this past year, so with the STU patch...
so that i have to remove Stu's patch first, right?
Secondly, after the non-STU patch version has crashed, i have to use the wx patch, no?