aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: [1] 2 3 ... 5

Author Topic: aMule SVN 9385 crash on 64bit Debian  (Read 35953 times)

Corwin

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 23
aMule SVN 9385 crash on 64bit Debian
« on: January 21, 2009, 06:22:35 PM »
amule: ../../src/xcb_lock.c:33: _XCBUnlockDisplay: Assertion `xcb_get_request_sent(dpy->xcb->connection) == dpy->request' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f6ec73e86f0 (LWP 17870)]
0x00007f6ec4572ed5 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00007f6ec4572ed5 in raise () from /lib/libc.so.6
#1  0x00007f6ec45743f3 in abort () from /lib/libc.so.6
#2  0x00007f6ec456bdc9 in __assert_fail () from /lib/libc.so.6
#3  0x00007f6ec19c13c7 in ?? () from /usr/lib/libX11.so.6
#4  0x00007f6ec19971de in XDefineCursor () from /usr/lib/libX11.so.6
#5  0x00007f6ec3b2ead0 in gdk_window_set_cursor () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00007f6ec57dc119 in wxWindow::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#7  0x00007f6ec5852c2d in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#8  0x00007f6ec5852c64 in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#9  0x00007f6ec5852ec4 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#10 0x00007f6ec57b33b6 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#11 0x00007f6ec297078b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007f6ec2973f5d in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007f6ec297448d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#14 0x00007f6ec3eb9737 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00007f6ec57ca798 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#16 0x00007f6ec5852cfb in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#17 0x00007f6ec50d6cbd in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#18 0x000000000068a5f3 in main (argc=1, argv=0x7fffcf52f9d8) at amule-gui.cpp:94
(gdb) bt full
#0  0x00007f6ec4572ed5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f6ec45743f3 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x00007f6ec456bdc9 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3  0x00007f6ec19c13c7 in ?? () from /usr/lib/libX11.so.6
No symbol table info available.
#4  0x00007f6ec19971de in XDefineCursor () from /usr/lib/libX11.so.6
No symbol table info available.
#5  0x00007f6ec3b2ead0 in gdk_window_set_cursor () from /usr/lib/libgdk-x11-2.0.so.0
No symbol table info available.
#6  0x00007f6ec57dc119 in wxWindow::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#7  0x00007f6ec5852c2d in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#8  0x00007f6ec5852c64 in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#9  0x00007f6ec5852ec4 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#10 0x00007f6ec57b33b6 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#11 0x00007f6ec297078b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#12 0x00007f6ec2973f5d in ?? () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#13 0x00007f6ec297448d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
#14 0x00007f6ec3eb9737 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#15 0x00007f6ec57ca798 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#16 0x00007f6ec5852cfb in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#17 0x00007f6ec50d6cbd in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#18 0x000000000068a5f3 in main (argc=1, argv=0x7fffcf52f9d8) at amule-gui.cpp:94
No locals.
(gdb) thread apply all bt

Thread 4 (Thread 0x4323d950 (LWP 17885)):
#0  0x00007f6ec7102fad in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x00007f6ec512dde9 in wxConditionInternal::WaitTimeout () from /usr/lib/libwx_baseu-2.8.so.0
#2  0x00007f6ec512f172 in wxSemaphoreInternal::WaitTimeout () from /usr/lib/libwx_baseu-2.8.so.0
#3  0x00000000007d8ed1 in CTimerThread::Entry (this=0x205d5f0) at Timer.cpp:64
#4  0x00007f6ec512f35a in wxThreadInternal::PthreadStart () from /usr/lib/libwx_baseu-2.8.so.0
#5  0x00007f6ec70fefc7 in start_thread () from /lib/libpthread.so.0
#6  0x00007f6ec46105ad in clone () from /lib/libc.so.6
#7  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x4223b950 (LWP 17878)):
#0  0x00007f6ec71060e1 in nanosleep () from /lib/libpthread.so.0
#1  0x00007f6ec5134e6c in wxMicroSleep () from /usr/lib/libwx_baseu-2.8.so.0
#2  0x00000000005d70de in UploadBandwidthThrottler::Entry (this=0x2950400) at UploadBandwidthThrottler.cpp:320
#3  0x00007f6ec512f35a in wxThreadInternal::PthreadStart () from /usr/lib/libwx_baseu-2.8.so.0
#4  0x00007f6ec70fefc7 in start_thread () from /lib/libpthread.so.0
#5  0x00007f6ec46105ad in clone () from /lib/libc.so.6
#6  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7f6ec73e86f0 (LWP 17870)):
#0  0x00007f6ec4572ed5 in raise () from /lib/libc.so.6
#1  0x00007f6ec45743f3 in abort () from /lib/libc.so.6
#2  0x00007f6ec456bdc9 in __assert_fail () from /lib/libc.so.6
#3  0x00007f6ec19c13c7 in ?? () from /usr/lib/libX11.so.6
#4  0x00007f6ec19971de in XDefineCursor () from /usr/lib/libX11.so.6
#5  0x00007f6ec3b2ead0 in gdk_window_set_cursor () from /usr/lib/libgdk-x11-2.0.so.0
#6  0x00007f6ec57dc119 in wxWindow::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#7  0x00007f6ec5852c2d in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#8  0x00007f6ec5852c64 in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#9  0x00007f6ec5852ec4 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#10 0x00007f6ec57b33b6 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#11 0x00007f6ec297078b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007f6ec2973f5d in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007f6ec297448d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#14 0x00007f6ec3eb9737 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x00007f6ec57ca798 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#16 0x00007f6ec5852cfb in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#17 0x00007f6ec50d6cbd in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#18 0x000000000068a5f3 in main (argc=1, argv=0x7fffcf52f9d8) at amule-gui.cpp:94
Logged

wuischke

  • Developer
  • Hero Member
  • *****
  • Karma: 183
  • Offline Offline
  • Posts: 4292
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #1 on: January 21, 2009, 07:26:48 PM »
Again the xcb_lock.c:33 and the cursor...

Please do me a favour and report this bug also the debian developers. We've got the same crash for Ubuntu (ref) and I begin to suspect this might somehow be related to the distribution gtk2 or xcb packages. (When you google this error you'll find a couple of them in the Ubuntu bug tracker).

Would you be so kind to include the link to the bug tracker entry?
Logged

Corwin

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 23
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #2 on: January 24, 2009, 12:30:41 PM »
Probably has more to do with user base, Ubuntu has more users than any other Linux distro.

The first Google result I pulled up was Red Hat:
https://bugzilla.redhat.com/show_bug.cgi?id=478689

« Last Edit: January 24, 2009, 12:36:43 PM by Corwin »
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #3 on: February 11, 2009, 05:03:23 PM »
I recently  moved to 64bits and I hit the bug.

Ummm, it seems WXGTK may not be taking some necessary precautions.

Could you try the attached patch? I'm testing it, but as the crash happens about 3 days uptime I will take a while to see how it works.


Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #4 on: February 11, 2009, 08:16:28 PM »
I don't think we call GUI functions from threads. At least I hope so...
There's something fishy like that in the part file importer iirc, but ordinary usage should be fine. So I don't expect it helps.

Quote from: http://tronche.com/gui/x/xlib/display/XInitThreads.html
It is only necessary to call this function if multiple threads might use Xlib concurrently.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #5 on: February 12, 2009, 12:55:50 AM »
Stu, note the crash happens in kinda "automatic" code (like changing the cursor). What is more, it crashes after several hours without user input. This smells like  threading bug to me.

By the way, similar crashes have been fixed that way. My backtrace gives 99% possibility for this to be an application (or WX) bug.

Of course the patch is not ready to go as is into aMule, but if it works it should give us a good idea on what is going on.

As a completely newbie to aMule code, I'm sorry I didn't have time to study the threading setting and supply a more in-depth analysis.

As the patch is completely harmless, I'd suggest everyone with the crash to test it.

I've been unable to get more than 3 days uptime since my move to 64bits, so in 4 days we'll have a good idea on how effective is the patch for me.

[I don't want to troll, but I find the gtk+wx combination to be a quite buggy setting (two bugs for me in a month), as least as compared with something rock-solid like QT Code quality of gtk+wx is not optimal as well]
Logged

Stu Redman

  • Administrator
  • Hero Member
  • *****
  • Karma: 214
  • Offline Offline
  • Posts: 3739
  • Engines screaming
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #6 on: February 12, 2009, 09:03:12 PM »
Quote from: btkaos on February 12, 2009, 12:55:50 AM
My backtrace gives 99% possibility for this to be an application (or WX) bug.
Which backtrace ? And how did you calculate that probability?


Quote from: btkaos on February 12, 2009, 12:55:50 AM
[I don't want to troll, but I find the gtk+wx combination to be a quite buggy setting (two bugs for me in a month), as least as compared with something rock-solid like QT Code quality of gtk+wx is not optimal as well]
That's not trolling.
I'd guess once you ported the whole thing to QT you'd find it has bugs/problems/limitations too.
Anyway, we're stuck with wx. a Mule without wx wouldn't be aMule, but an entirely different project.

BtW: I don't know much about 64 bit Linux, except that it sucks and always makes strange pointer corruptions and crashes.  >:(
(That's a better attempt at trolling.  ;))
With 64 bit Windows you still can run 32 bit apps. What about Linux ? Does 32 bit aMule run on 64 bit Linux ? It doesn't take 4Gb of Memory you know. If it runs I'd just drop the 64 bit builds.
Logged
The image of mother goddess, lying dormant in the eyes of the dead, the sheaf of the corn is broken, end the harvest, throw the dead on the pyre -- Iron Maiden, Isle of Avalon

wuischke

  • Developer
  • Hero Member
  • *****
  • Karma: 183
  • Offline Offline
  • Posts: 4292
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #7 on: February 12, 2009, 09:50:17 PM »
Microsoft (or Apple) use duplicate libraries (both in 32 bit/64 bit or intel/ppc) for backwards compatilibity with older software.

Well, you can do the same and install 32 bit libraries. If you install all necessary libraries in 32 bit, you can use a 32 bit aMule on a 64 bit Linux. Some distributions do this to get skype, zattoo or another closed source 32 bit-only software to work. It is, however, not necessary with open source applications and therefore not done.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #8 on: February 12, 2009, 10:13:42 PM »
Oh, I'm sorry STU, I was quite careless in my debugging session and lost the backtrace. I'm really sorry about my newbie error of not saving the backtrace before proceed to actually debugging the application. So this is why I didn't post my backtrace.

However, the backtrace itself showed that Xlib was being called from two different threads. The codepath both in aMule, GTK+ and WX were perfect. Every variable was right, the bug lied in the use of Xlib.

I must admit I said 99% of probability meaning "it is really likely the bug is a multithreading bug", look, no user action, just some race condition and bang!

aMule is not the only app affected, For instance see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513829 (In particular, note how the bug is not distro-specific, as Fedora is also affected, and how the XInitThreads() call must be placed *before* gtk_init() )

I said 99% percent because with the superficial debugging I did there's no way to prove it. However I'm 28 hours uptime and aMule is now rock-solid with patch.

Regards, Billkaos
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #9 on: February 12, 2009, 10:16:11 PM »
By the way, use of gdk_threads_init() is not needed as aMule indeed is using GTK+ right, only from one thread. If two or more threads were to interact with gtk+, this call must be added.
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #10 on: February 13, 2009, 01:08:22 AM »
Quote from: Stu Redman on February 12, 2009, 09:03:12 PM
BtW: I don't know much about 64 bit Linux, except that it sucks and always makes strange pointer corruptions and crashes.  >:(
(That's a better attempt at trolling.  ;))
With 64 bit Windows you still can run 32 bit apps. What about Linux ? Does 32 bit aMule run on 64 bit Linux ? It doesn't take 4Gb of Memory you know. If it runs I'd just drop the 64 bit builds.
That only works when you are in the < 4Gb of RAM range of memory. I have machines with 8Gb and 16Gb of memory, so running 32bits is pointless.

Anyways, this is not a 32 vs 64 bits bug, but a threading one.
« Last Edit: February 13, 2009, 01:14:48 AM by btkaos »
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 169
  • Offline Offline
  • Posts: 2685
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #11 on: February 13, 2009, 12:51:47 PM »
Quote from: btkaos on February 12, 2009, 10:13:42 PM
However, the backtrace itself showed that Xlib was being called from two different threads. The codepath both in aMule, GTK+ and WX were perfect. Every variable was right, the bug lied in the use of Xlib.

If you ever can reproduce the bug, please think of us and post a backtrace. I'm really interested in it (maybe we can do something against it, or it might reveal other bugs).

Quote from: btkaos on February 11, 2009, 05:03:23 PM
Ummm, it seems WXGTK may not be taking some necessary precautions.

I'd say the patch should better be sent to the wxGTK developers. I mean it'd be better to patch wxGTK.
Logged
concordia cum veritate

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #12 on: February 14, 2009, 03:42:48 AM »
Quote from: GonoszTopi on February 13, 2009, 12:51:47 PM
If you ever can reproduce the bug, please think of us and post a backtrace. I'm really interested in it (maybe we can do something against it, or it might reveal other bugs).
It seems I miscalculated the probability and I'm still clueless about what is going on.

I got:
Code: [Select]
Thread 1 (Thread 0x7f00414a7780 (LWP 2455)):
#0  0x00007f003e92d015 in raise () from /lib/libc.so.6
#1  0x00007f003e92eb83 in abort () from /lib/libc.so.6
#2  0x00007f003e925d89 in __assert_fail () from /lib/libc.so.6
#3  0x00007f003e63b867 in _XCBUnlockDisplay (dpy=0x2c66a00) at ../../src/xcb_lock.c:33
#4  0x00007f003e61124e in XDefineCursor (dpy=0x2c66a00, w=65012340, cursor=65011719)
    at ../../src/DefCursor.c:47
#5  0x00007f003dbcc178 in gdk_window_x11_set_cursor (window=0x5753dc0, cursor=0x4ff5640)
    at /build/buildd/gtk+2.0-2.14.4/gdk/x11/gdkwindow-x11.c:2912
#6  0x00007f003fe2acf5 in wxToolBar::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#7  0x00007f003fe09413 in wxFrame::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#8  0x00007f003fe35e7d in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#9  0x00007f003fe36114 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#10 0x00007f003fd956b4 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#11 0x00007f003c0a2d3b in IA__g_main_context_dispatch (context=0x2c43950)
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2144
#12 0x00007f003c0a650d in g_main_context_iterate (context=0x2c43950, block=1, dispatch=1,
    self=<value optimized out>) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2778
#13 0x00007f003c0a6a3d in IA__g_main_loop_run (loop=0x2cd3020)
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
#14 0x00007f003df33727 in IA__gtk_main () at /build/buildd/gtk+2.0-2.14.4/gtk/gtkmain.c:1200
#15 0x00007f003fdacd18 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#16 0x00007f003fe35f4b in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#17 0x00007f003f6d073d in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
#18 0x0000000000524a52 in main ()

We can inspect frame #3, and print the values involved in the assertion:
Code: [Select]
(gdb) print dpy->xcb->connection
$24 = (xcb_connection_t *) 0x2c67440
(gdb) print dpy->request
$25 = 4294967297$25 looks suspicious, as it is 2^32. It seems an off-by-one bug. However I'm not expert in 64-bit debugging, so I may be missing something.

What is really curious is frame #6, which calls gdk_windows_set_cursor() from an idle handler:
Code: [Select]
void wxToolBar::OnInternalIdle()
{
    // Check if we have to show window now
    if (GtkShowFromOnIdle()) return;
   
    wxCursor cursor = m_cursor;
    if (g_globalCursor.Ok()) cursor = g_globalCursor;

    if (cursor.Ok())
    {
        /* I now set the cursor the anew in every OnInternalIdle call
           as setting the cursor in a parent window also effects the
           windows above so that checking for the current cursor is
           not possible. */

        if (HasFlag(wxTB_DOCKABLE) && (m_widget->window))
        {
            /* if the toolbar is dockable, then m_widget stands for the
               GtkHandleBox widget, which uses its own window so that we
               can set the cursor for it. if the toolbar is not dockable,
               m_widget comes from m_toolbar which uses its parent's
               window ("windowless windows") and thus we cannot set the
               cursor. */
            gdk_window_set_cursor( m_widget->window, cursor.GetCursor() );
        }
    // BOOM!!

Quoting http://library.gnome.org/devel/gdk/stable/gdk-Threads.html

Quote
Idles, timeouts, and input functions from GLib, such as g_idle_add(), are executed outside of the main GTK+ lock. So, if you need to call GTK+ inside of such a callback, you must surround the callback with a gdk_threads_enter()/gdk_threads_leave() pair or use gdk_threads_add_idle_full() which does this for you. However, event dispatching from the mainloop is still executed within the main GTK+ lock, so callback functions connected to event signals like GtkWidget::button-press-event, do not need thread protection.

I wonder if it is related
« Last Edit: February 14, 2009, 03:44:41 AM by btkaos »
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Full backtrace, not really useful
« Reply #13 on: February 14, 2009, 03:46:32 AM »
Code: [Select]
(gdb) thread apply all bt full

Thread 4 (Thread 0x40945950 (LWP 2467)):
#0  0x00007f00410b055d in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f003f728699 in wxConditionInternal::WaitTimeout () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00007f003f729a22 in wxSemaphoreInternal::WaitTimeout () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#3  0x0000000000604ed8 in CTimerThread::Entry ()
No locals.
#4  0x00007f003f729c0a in wxThreadInternal::PthreadStart () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#5  0x00007f00410ac3ea in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6  0x00007f003e9e0cbd in clone () from /lib/libc.so.6
No symbol table info available.
#7  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 2 (Thread 0x41df6950 (LWP 2465)):
#0  0x00007f00410b3851 in nanosleep () from /lib/libpthread.so.0
No symbol table info available.
#1  0x00007f003f72f8bc in wxMicroSleep () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#2  0x00000000004f5032 in UploadBandwidthThrottler::Entry ()
No locals.
#3  0x00007f003f729c0a in wxThreadInternal::PthreadStart () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#4  0x00007f00410ac3ea in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00007f003e9e0cbd in clone () from /lib/libc.so.6
No symbol table info available.
#6  0x0000000000000000 in ?? ()
No symbol table info available.

Thread 1 (Thread 0x7f00414a7780 (LWP 2455)):
#0  0x00007f003e92d015 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f003e92eb83 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x00007f003e925d89 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3  0x00007f003e63b867 in _XCBUnlockDisplay (dpy=0x2c66a00) at ../../src/xcb_lock.c:33
__PRETTY_FUNCTION__ = "_XCBUnlockDisplay"
#4  0x00007f003e61124e in XDefineCursor (dpy=0x2c66a00, w=65012340, cursor=65011719)
    at ../../src/DefCursor.c:47
No locals.
#5  0x00007f003dbcc178 in gdk_window_x11_set_cursor (window=0x5753dc0, cursor=0x4ff5640)
    at /build/buildd/gtk+2.0-2.14.4/gdk/x11/gdkwindow-x11.c:2912
impl = (GdkWindowImplX11 *) 0x5753e60
xcursor = 6
#6  0x00007f003fe2acf5 in wxToolBar::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#7  0x00007f003fe09413 in wxFrame::OnInternalIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#8  0x00007f003fe35e7d in wxAppBase::SendIdleEvents () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#9  0x00007f003fe36114 in wxAppBase::ProcessIdle () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#10 0x00007f003fd956b4 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#11 0x00007f003c0a2d3b in IA__g_main_context_dispatch (context=0x2c43950)
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2144
No locals.
#12 0x00007f003c0a650d in g_main_context_iterate (context=0x2c43950, block=1, dispatch=1,
    self=<value optimized out>) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2778
max_priority = 300
timeout = 0
some_ready = 1
nfds = 200
allocated_nfds = <value optimized out>
fds = (GPollFD *) 0xbe8a5e0
__PRETTY_FUNCTION__ = "g_main_context_iterate"
#13 0x00007f003c0a6a3d in IA__g_main_loop_run (loop=0x2cd3020)
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
self = (GThread *) 0x2c44cc0
__PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#14 0x00007f003df33727 in IA__gtk_main () at /build/buildd/gtk+2.0-2.14.4/gtk/gtkmain.c:1200
tmp_list = (GList *) 0x0
functions = (GList *) 0x0
init = (GtkInitFunction *) 0x5a28600
loop = <value optimized out>
#15 0x00007f003fdacd18 in wxEventLoop::Run () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#16 0x00007f003fe35f4b in wxAppBase::MainLoop () from /usr/lib/libwx_gtk2u_core-2.8.so.0
No symbol table info available.
#17 0x00007f003f6d073d in wxEntry () from /usr/lib/libwx_baseu-2.8.so.0
No symbol table info available.
#18 0x0000000000524a52 in main ()
No locals.
(gdb)
[I need to fix wx debugging information]
Logged

btkaos

  • Global Moderator
  • Sr. Member
  • *****
  • Karma: 110
  • Offline Offline
  • Posts: 486
  • Kaos is infinite!
Re: aMule SVN 9385 crash on 64bit Debian
« Reply #14 on: February 14, 2009, 04:14:34 AM »
I made a mistake.

dpy->request is the sequence number, and I didn't print it right in gdb:

Quote
(gdb) print xcb_get_request_sent(dpy->xcb->connection)
$32 = 1
(gdb) print dpy->request
$33 = 4294967297

See?, the display sequence number is 2^32+1 (4294967297), but xcb mangled it to 32 bits, so an overflow occurred, which in fact triggers the bug.

So the bug seems in xcb and this commit may fix it:

http://cgit.freedesktop.org/xcb/libxcb/commit/?id=baff35a04b0e8d21821850a405a550d86a8aeb6f

I'm testing the fixed libxcb right now. As it is an overflow it explains the long time to reach it, just when amule reaches sequence number 4294967296 (wow!) It also explains why other applications where hitting the bug earlier: They used sequence numbers more quickly, i.e. are more X11 intensive.
« Last Edit: February 14, 2009, 05:00:41 PM by btkaos »
Logged
Pages: [1] 2 3 ... 5
« previous next »