Bug 812

Another backtrace

intersect abort
krdc: ../../src/xcb_io.c:249: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff179bba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff179bba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff179f6b0 in abort () at abort.c:92
#2  0x00007ffff1794a71 in __assert_fail (assertion=0x7ffff2798738 "(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)",
    file=<value optimized out>, line=249, function=0x7ffff27987d0 "process_responses") at assert.c:81
#3  0x00007ffff272c473 in ?? () from /usr/lib/libX11.so.6
#4  0x00007ffff272cd07 in _XEventsQueued () from /usr/lib/libX11.so.6
#5  0x00007ffff27153fd in XPending () from /usr/lib/libX11.so.6
#6  0x00007ffff71cfd49 in QEventLoop::processEvents (this=0x6cd020, flags=<value optimized out>) at kernel/qeventloop_x11.cpp:150
#7  0x00007ffff7235b11 in QEventLoop::enterLoop (this=0x6cd020) at kernel/qeventloop.cpp:201
#8  0x00007ffff72359c2 in QEventLoop::exec (this=0x292f) at kernel/qeventloop.cpp:148
#9  0x000000000042b6c5 in main (argc=<value optimized out>, argv=<value optimized out>)
    at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/main.cpp:158
(gdb)

Threaded backtrace:

(gdb) thread apply all bt

Thread 3 (Thread 0x7fffe3fff700 (LWP 32541)):
#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:212
#1  0x00007ffff74fa6bb in QWaitCondition::wait (this=0x7f9638, mutex=0x7f9628, time=<value optimized out>) at tools/qwaitcondition_unix.cpp:304
#2  0x0000000000432924 in WriterThread::run (this=0x7f9618) at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/vnc/threads.cpp:318
#3  0x00007ffff72194cb in QThreadInstance::start (_arg=<value optimized out>) at kernel/qthread_unix.cpp:122
#4  0x00007ffff4b2f971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#5  0x00007ffff184e92d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fffeb164700 (LWP 32512)):
#0  0x00007ffff18472c3 in select () at ../sysdeps/unix/syscall-template.S:82
#1  0x00000000004404e9 in ReadFromRFBServer (out=0x7fffeb163ae0 "", n=1)
    at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/vnc/sockets.c:95
#2  0x000000000043d14a in HandleRFBServerMessage () at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/vnc/rfbproto.c:886
#3  0x0000000000432420 in ControllerThread::run (this=0x7f95d0) at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/vnc/threads.cpp:139
#4  0x00007ffff72194cb in QThreadInstance::start (_arg=<value optimized out>) at kernel/qthread_unix.cpp:122
#5  0x00007ffff4b2f971 in start_thread (arg=<value optimized out>) at pthread_create.c:304
#6  0x00007ffff184e92d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7f95940 (LWP 32494)):
#0  0x00007ffff179bba5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff179f6b0 in abort () at abort.c:92
#2  0x00007ffff1794a71 in __assert_fail (assertion=0x7ffff2798738 "(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)",
    file=<value optimized out>, line=249, function=0x7ffff27987d0 "process_responses") at assert.c:81
#3  0x00007ffff272c473 in ?? () from /usr/lib/libX11.so.6
#4  0x00007ffff272cd07 in _XEventsQueued () from /usr/lib/libX11.so.6
#5  0x00007ffff27153fd in XPending () from /usr/lib/libX11.so.6
#6  0x00007ffff71cfd49 in QEventLoop::processEvents (this=0x6cd020, flags=<value optimized out>) at kernel/qeventloop_x11.cpp:150
#7  0x00007ffff7235b11 in QEventLoop::enterLoop (this=0x6cd020) at kernel/qeventloop.cpp:201
#8  0x00007ffff72359c2 in QEventLoop::exec (this=0x7eee) at kernel/qeventloop.cpp:148
#9  0x000000000042b6c5 in main (argc=<value optimized out>, argv=<value optimized out>)
    at /home/eldarion/123456/kdenetwork/kdenetwork-trinity-3.5.13/./krdc/main.cpp:158

This can be reliably reproduced by loading speedtest.net in Firefox and moving the cursor continuously over the flash plugin area while it is loading.

(In reply to comment #3)
> This can be reliably reproduced by loading speedtest.net in Firefox and moving
> the cursor continuously over the flash plugin area while it is loading.

This reproduces the bug about 25% of the time--sometimes just opening a new Firefox tab causes the crash.

Sporadically I also get this error:

X Error: BadShmSeg (invalid shared segment parameter) 163
  Major opcode:  147
  Minor opcode:  3
  Resource id:  0x5a0013f
krdc: ../../src/xcb_io.c:249: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.

Program received signal SIGABRT, Aborted.

Problem traced to lack of XInitThreads() call on application startup.

Other threaded Qt3 applications are likely affected by this bug, which was brought on by the switch to using xcb as a backend for libX11, therefore the call to XInitThreads() should likely be made once in all new QApplication objects when threading is enabled.

Fixed in GIT hash 1f39650.

(Odpověď na komentář #6)
> Fixed in GIT hash 1f39650.

I tried to add a patch 1db4f237, but applications still fall 3.5.13 immediately at startup - kdesktop, kded, Konqueror.

(In reply to comment #7)
> (Odpověď na komentář #6)
> > Fixed in GIT hash 1f39650.
> 
> I tried to add a patch 1db4f237, but applications still fall 3.5.13 immediately
> at startup - kdesktop, kded, Konqueror.

You are going to need to generate a backtrace and also include details of your graphics hardware/Xorg version/XLib version.  This should not be failing.

Created attachment 490 [details]
Backtrace for kdesktop crash

Created attachment 491 [details]
Backtrace for konqueror crash

Created attachment 492 [details]
Backtrace for kicker crash

Bug is not dependent on the graphics hardware - it's falling with various cards.

If I remember correctly, I tried Xorg from squeeze (1:7.5+8+squeeze1) - and now recorded backtraces is with Xorg from the squeeze-backports (1:7.6+8~bpo60+1).

I was looking for information on how the problem dealt with XInitThreads upstrem QT. I found, including an interesting explanation of why not to put it directly in QT:

"We can't have this enabled by default both because of performance reasons (every single X11 call needs to lock/unlock a mutex), and also because of the old lock-up bug."

https://bugs.freedesktop.org/show_bug.cgi?id=40298
https://bugreports.qt-project.org/browse/QTBUG-200?focusedCommentId=124006&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

It seems more appropriate to call XInitThreads just in applications where it is needed.

The trouble is knowing exactly which applications are affected.  Many will seem to work just fine and segfault on certain computers in certain use cases.  Most users won't bother filing a bug report for sporadic crashes, so we would be shipping software that we know will randomly crash.  Personally I'd prefer the slight performance penalty for guaranteed stability.

Tim

Created attachment 624 [details]
Backtrace for konqueror crash

I install certain other dbg packages and update backtrace.
I see that programs crash only when run through the kinit.
For example: Konquror can not run from the T Menu, but it can run from the konsole.
Crash follows always after QXIMInputContext::init_xim.

Created attachment 625 [details]
Backtrace for kicker crash

I found a solution, but I need advice. When searching for the causes of crashes, I discovered that the problem occurs with older versions of libX11 - 1.3.3 and earlier. I tried to update to 1.3.6 (latest in a series 1.3.x) and crashes are stopped.

libX11 in distributions
- squeeze: 2:1.3.3-4
- wheezy: 2:1.4.99.901-2
- lucid: 2:1.3.2-1ubuntu3
- maverick: 2:1.3.3-3ubuntu1
- natty: 2:1.4.2-1ubuntu3
- oneiric: 2:1.4.4-2ubuntu1
- precise: 2:1.4.99.1-0ubuntu2

The problem thus concerns the squeeze, lucid, and maverick. What should I do next? Prepare libX11 1.3.6 for all three? (For lucid perhaps earlier - because of other dependencies.) Or find a specific patch and incorporate it into the version libx11, which is in specific distribution?

(In reply to comment #17)
> I found a solution, but I need advice. When searching for the causes of
> crashes, I discovered that the problem occurs with older versions of libX11 -
> 1.3.3 and earlier. I tried to update to 1.3.6 (latest in a series 1.3.x) and
> crashes are stopped.

This explains quite a bit--thanks for the debugging!  The best thing is probably to use a distro-sepcific patch (in ./debian/patches/) to revert 1db4f237 for distributions that provide  libX11 <= 1.3.3.  Obviously this will cause issues with krdc crashing, but the solution to that is for the end user to upgrade to a distro which provides a stable libX11 > 1.3.3.

Tim

Should those building with libX11 <= 1.3.3 revert the patch in 1db4f237?

(In reply to comment #19)
> Should those building with libX11 <= 1.3.3 revert the patch in 1db4f237?

Yes.

(Odpověď na komentář #20)
> (In reply to comment #19)
> > Should those building with libX11 <= 1.3.3 revert the patch in 1db4f237?
> 
> Yes.

Would have to be reverted both - not only 1db4f237 but 1f39650. But then krdc will fall and fall and fall... And sometimes also other programs. This is not attractive solution.

I started looking for more specific cause.

The first finding is that when the program is run independently (such as from Konsole), it works, but when run through kdeinit (from menu, opening a file in Konqueror,...), crashes.

To reduce the number of changes in libx11, I have tested with versions such crash will cease: 1.3.3 - crashes, 1.3.4 - crashes, 1.3.5 - crashes, 1.3.6 - no crashes! The advantage is that between 1.3.5 and 1.3.6 are a few changes. But nothing, that would apparently be associated with the locking!

So I tried patches:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=77cb2bda308b39dc0a8267f18d92e7b4bf178aa1
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=b3ff091678e900128f209b9d64bfac36228a355b
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=e90ec71b870ac15f52e41162e61974d16b63d3a2
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=a32370c0854c8ad6f526dd997f14dbe3f466d4db

But crash stopped until after the patch that removes file XKeysymDB that after previous patches is not used:
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=50b4b07073bd46cbef3627c160a240bd2a2b99d5

It looks very mysterious. And really - when I tried to create a completely empty file /usr/share/X11/XKeysymDB, the crashes came back - because of an this empty file! And this applies also to libx11 version 1.4.x! Scary. Error was not actually "fixed", but "rounded".

I searched so deeply again. I found that keysymdb (libx11/src/StrKeysym.c) used for calling functions XrmQGetResource, XrmEnumerateDatabase (possibly others - libx11/src/Xrm.c) under some circumstances has not created mutex. Attempt to lock leads to crash.

Now I have prepared three options:
1. Upgrade libx11 to 1.3.6 for Lucid, Maverick and Squeeeze.
2. Patches of the above commits, which cancels the need XKeysymDB, to use it with libx11 from specific distribution
3. Patch that adds a recreation of the mutex (see attachment), to use it with libx11 from specific distribution

But, unfortunately, the cause is still unknown. I looked into XInitThreads that repeated execution is internally treated. Repeated calls XInitThreads therefore should not be a problem. I tried it both ways - to always run XInitThreads - regardless qt_is_gui_used and !display, but the problem still persists. By examining libx11 I also did not find anything. So still do not know the cause - the patch solves only a consequence.

Created attachment 626 [details]
Patch for libx11 - recreate mutex

Please, I welcome any help, because patches 1f39650 and 1db4f237 are very helpful. And I certainly want them to be in 3.5.13.1.

I can confirm - I have it - final solution!

Since the beginning I searched in qt3 => adding to XInitThreads qt3 crashes caused, and libx11 => the crash occurred just in lib11. Now I was looking for but from a completely different angle - the accidents occurred only when the program was run through kdeinit. Therefore, I focused on kdelibs - kinit.

And I found it! Kinit is not initialized as a full QT application == XInitThreads is not called from QT3. However in kinit is initiated XIM, but without previous call XInitThreads. And that was exactly what is needed. The application therefore came to an environment where XIM already initialized, but no locks.

New patch that removes the need to update libx11 as well as its patching. The patch fixes tdelibs... and is my favorite - one-line fix ;)

Created attachment 628 [details]
Add XInitThreads also into kinit

(In reply to comment #25)
> Created attachment 628 [details]
> Add XInitThreads also into kinit

Very good work!

Committed to GIT in hash 6c806af.

Okay, you wiz kids. What do the recent patches mean to me? Do I still need to reverse previous patches when building against 1.3.3? Or just build as usual from GIT?

BTW, the other problem with Konqueror not starting was solved by rebuilding all packages, mostly tdeaddons.

(Odpověď na komentář #27)
> Okay, you wiz kids. What do the recent patches mean to me? Do I still need to
> reverse previous patches when building against 1.3.3? Or just build as usual
> from GIT?
> 
> BTW, the other problem with Konqueror not starting was solved by rebuilding all
> packages, mostly tdeaddons.

Last patch supersedes all here previous. No need to update libx11. No need to patch libx11. Crashes associated with XInitThreads in QT × locking in libx11 (Xrm.c) are solved by this one line added to tdelibs.

Is there some reason to leave open this bug?

*** Bug 486 has been marked as a duplicate of this bug. ***