GNOME Bugzilla – Bug 138794
video drag locks mouse
Last modified: 2005-01-20 14:39:35 UTC
1) start playing a movie 2) start dragging video and dropping it on the video screen quickly mouse pointer turns in to drag cursor with two slightly overlapping O's in as the drag symbol. I can move the mouse but I can't click or use the keyboard for anything.
This is http://bugzilla.gnome.org/show_bug.cgi?id=127586 again. But I am now running gtk+ 2.4. And the mouse cursor is different.
I'm getting this to! A real pain, since I one of those "like to drag stuff for no apparent reason"-people. totem version 0.99.9 with the xine backend.
I managed to reproduce the problem. God knows what the problem is. Maybe me soon as well.
It hangs in _XUnregisterFilter for me. XUnregisterFilter is a XInput function. Another one of those deadlocks in libXi? Could you check that your gtk+ is compiled against libXi? $ ldd /usr//lib/libgtk-x11-2.0.so.0 | grep Xi libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x00e63000)
yes, my gtk+ is compiled against libXi % ldd /usr/lib/libgtk-x11-2.0.so.0.400.0|grep Xi libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x406af000)
Doesn't have anything to do with libXi, as my tests showed. _XUnregisterFilter is a libX11.so function. There seems to be a memory corruption somewhere, as DND works properly under valgrind.
The backtrace with the LinuxThreads: 0x006b7e64 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
+ Trace 45948
And an even better one: 0x002cbe64 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
+ Trace 45951
Another better stack, and some debug from the x.org libs: Using host libthread_db library "/lib/tls/libthread_db.so.1". 0x009b0e64 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
+ Trace 45966
Pending.c line 50: thread 4000 got display lock _XEventsQueued called in thread 4000 _XPushReader called in thread 4000, pushing 8d04ab0 _XPopReader called in thread 4000, popping 8d04ab0 Pending.c line 55: thread 4000 unlocking display MoveWin.c line 39: thread 4000 got display lock MoveWin.c line 59: thread 4000 unlocking display RaiseWin.c line 39: thread 4000 got display lock RaiseWin.c line 44: thread 4000 unlocking display GetWAttrs.c line 99: thread 4000 got display lock _XPushReader called in thread 4000, pushing 8d04ab0 _XReply called in thread 4000, adding 8d04ab0 to cvl XlibInt.c line 487: thread 4000 unlocking display XlibInt.c line 495: thread 4000 got display lock thread 4000 _XWaitForReadable returning _XPopReader called in thread 4000, popping 8d04ab0 GetWAttrs.c line 141: thread 4000 unlocking display SelInput.c line 39: thread 4000 got display lock SelInput.c line 45: thread 4000 unlocking display _XPushReader called in thread 4000, pushing 8d04ab0 _XReply called in thread 4000, adding 8d04ab0 to cvl XlibInt.c line 487: thread 4000 unlocking display Xlib ERROR: XlibInt.c line 487 thread 4000: unlocking display that is not lockedXlib ERROR: XlibInt.c line 495 thread 4000 locking display it did not unlock XlibInt.c line 495: thread 4000 got display lock thread 4000 _XWaitForReadable returning _XPopReader called in thread 4000, popping 8d04ab0 _XPushReader called in thread 4000, pushing 8d04ab0 _XReply called in thread 4000, adding 8d04ab0 to cvl XlibInt.c line 487: thread 4000 unlocking display XlibInt.c line 495: thread 4000 got display lock thread 4000 _XWaitForReadable returning _XPopReader called in thread 4000, popping 8d04ab0 _XPushReader called in thread 4000, pushing 8d04ab0 _XReply called in thread 4000, adding 8d04ab0 to cvl XlibInt.c line 487: thread 4000 unlocking display XlibInt.c line 495: thread 4000 got display lock thread 4000 _XWaitForReadable returning _XPopReader called in thread 4000, popping 8d04ab0 _XPushReader called in thread 4000, pushing 8d04ab0 _XReply called in thread 4000, adding 8d04ab0 to cvl XlibInt.c line 487: thread 4000 unlocking display XlibInt.c line 495: thread 4000 got display lock thread 4000 _XWaitForReadable returning _XPopReader called in thread 4000, popping 8d04ab0 Xlib ERROR: IntAtom.c line 255 thread 4000: locking display already locked at SelInput.c line 39 Killed
From fd.o, try Xlib with XCB: <daniels> hadess: /cvs/xcb, check out xcb-proto and xcb, then rebuild libx11 with --with-xcb <daniels> hadess: you'll need to edit x11.pc.in to have -lXCB in its linking tho
This problem seems to have gone away (kind of). With recent debian I can click and drag all I want. Occasionally the drag will stay active when I am not holding down a mouse button (To get this to happen, just click quickly and often and drag the mouse.. it happens easy enough for me) but if I click the drag ends. I think the new behaviour is just a less serious version of the same problem (a drag staying active when mouse button isn't pressed)
*** Bug 143085 has been marked as a duplicate of this bug. ***
*** Bug 145133 has been marked as a duplicate of this bug. ***
still always reproducible with Fedora Core 2 and totem 0.99.15 :-(
*** Bug 149168 has been marked as a duplicate of this bug. ***
The bug is definitely in the underlying libraries, as it now works perfectly for me (video canvas d'n'd and playlist reorganisation with d'n'd as well) with: xorg-x11-6.7.99.903-6 (X.org 6.8 prerelease from Fedora's Rawhide) and gtk2-2.4.9-7 I'll consider this bug fixed as a non-Totem bug. Feel free to put comments in if you can reproduce with a different version of X and same of gtk+, or vice-versa.
*** Bug 162374 has been marked as a duplicate of this bug. ***
*** Bug 164388 has been marked as a duplicate of this bug. ***
I've upgraded to 6.8 but still can reproduce it. My Fedora rpms: xorg-x11-libs-6.8.1-12 totem-0.100-1 libxine1-1.0-0 gtk2-2.4.13 But I agree that it's not a totem problem anyway.
But after upgrade of gtk to gtk2-2.6.1 everything start work fine.