Deadlock with xine-ui and Fedora 14

Hi,

xine has begun deadlocking ever since I upgraded to Fedora 14, and I think it 
might be related somehow to the thread in xine-ui that prevents the screensaver 
from activating. I have (so far) managed to avoid the deadlock with the 
following hack:

diff -r 2bb1508f3255 src/xitk/videowin.c
--- a/src/xitk/videowin.c	Thu Oct 21 00:15:10 2010 +0200
+++ b/src/xitk/videowin.c	Mon Nov 08 00:12:36 2010 +0000
@@ -2288,7 +2288,7 @@

   long int idle = 0;

-  if(gGui->ssaver_enabled && ((idle = video_window_get_ssaver_idle()) >= (long 
int) gGui->ssaver_timeout)) {
+  if(0 && gGui->ssaver_enabled && ((idle = video_window_get_ssaver_idle()) >= 
(long int) gGui->ssaver_timeout)) {
     idle = 0;
     /* fprintf(stderr, "resetting ssaver\n"); */

According to pstack:

Thread 17 (Thread 0xb6b91b70 (LWP 3363)):
#0  0xb77f6424 in __kernel_vsyscall ()
#1  0x478e498b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x479621e5 in _XConditionWait () from /usr/lib/libX11.so.6
#3  0x47961ba1 in _XDisplayLockWait () from /usr/lib/libX11.so.6
#4  0x4797d433 in _XReply () from /usr/lib/libX11.so.6
#5  0xb77824fe in XScreenSaverQueryInfo () from /usr/lib/libXss.so.1
#6  0x080a678f in video_window_get_ssaver_idle ()
#7  0x080a67eb in video_window_reset_ssaver ()
#8  0x080846a4 in slider_loop ()

i.e. XScreenSaverQueryInfo() wants to lock the display. And it may (or may not) 
be a coincidence, but xitk_run() is always trying to lock the display when the 
deadlock happens too:

Thread 1 (Thread 0xb74fd730 (LWP 12673)):
#0  0xb7760424 in __kernel_vsyscall ()
#1  0x478e498b in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x479621e5 in _XConditionWait () from /usr/lib/libX11.so.6
#3  0x47961ba1 in _XDisplayLockWait () from /usr/lib/libX11.so.6
#4  0x47962330 in _XLockDisplay () from /usr/lib/libX11.so.6
#5  0x4796195b in XLockDisplay () from /usr/lib/libX11.so.6
#6  0x080cbc4d in xitk_run ()
#7  0x0805c479 in gui_run ()
#8  0x0806ca66 in main ()

I believe that this corresponds to the following section of xitk_run():

    select(xconnection + 1, &r, 0, 0, &tv);

    XLOCK(gXitk->display);
    got_event = (XPending(gXitk->display) != 0);
    if( got_event )
      XNextEvent(gXitk->display, &myevent);
    XUNLOCK(gXitk->display);

    while(got_event == True) {

However, doesn't it take *two* locks to create a deadlock situation? The display 
lock certainly looks like one of them, but I can't see where the other one is 
being taken. Could it be another lock internal to X?

Any thoughts from anyone more familiar with xine-ui's and X's locking model 
would be much appreciated. In the meantime, I have raised the value of 
gui.screensaver_timeout in my config file from 10 seconds to 270 seconds.

Cheers,
Chris


      

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev