From: Chris R. <ran...@ya...> - 2010-11-08 00:38:00
|
Hi, I have dug further into this deadlock, 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 |
From: lorenzodes <lor...@fa...> - 2010-11-08 10:04:51
|
Il 08/11/2010 01:37, Chris Rankin ha scritto: > Hi, [...] > > 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 You should post a backtrace with full debug information. The ones you've posted so far are pretty obscure. |
From: Chris R. <ran...@ya...> - 2010-11-08 11:10:46
|
----- Original Message ---- > You should post a backtrace with full debug information. The ones > you've posted so far are pretty obscure. I tried creating a backtrace with gdb, but gdb did not give me my command line back when xine-ui deadlocked and so I tried hitting Ctrl-C. Unfortunately, I think Ctrl-C killed almost all of the threads, which made the backtrace meaningless. This is why I resorted to using pstack. I have already posted the complete pstack output to xine-devel, although I'm not sure that pstack understands debug symbols. Cheers, Chris |
From: Paul M. <pau...@us...> - 2010-11-08 11:22:29
|
Am Montag, den 08.11.2010, 03:10 -0800 schrieb Chris Rankin: > > You should post a backtrace with full debug information. The ones > > you've posted so far are pretty obscure. > > I tried creating a backtrace with gdb, but gdb did not give me my command line > back when xine-ui deadlocked and so I tried hitting Ctrl-C. Unfortunately, I > think Ctrl-C killed almost all of the threads, which made the backtrace > meaningless. What do you mean by that? You can instruct GDB to write to a file. (gdb) set logging file /tmp/20101108--xine.backtrace Or you could have run GDB through a screen [1] session possibly in combination with SSH. […] Thanks, Paul [1] http://www.gnu.org/software/screen/ |
From: lorenzodes <lor...@fa...> - 2010-11-08 11:33:32
|
Il 08/11/2010 12:10, Chris Rankin ha scritto: > I tried creating a backtrace with gdb, but gdb did not give me my command line > back when xine-ui deadlocked and so I tried hitting Ctrl-C. Unfortunately, I > think Ctrl-C killed almost all of the threads, which made the backtrace > meaningless. gdb should intercept ctrl-c before it gets sent to the debugged program unless set to do differently. Anyway recompile both xine and xine-ui with debug symbls, run xine-ui and wait until it freezes. When xine-ui deadlocks, switch to a terminal and write: gdb xine $(pidof xine) > This is why I resorted to using pstack. I have already posted the complete > pstack output to xine-devel, although I'm not sure that pstack understands debug > symbols. I don't use pstack myself, but AFAIK it should be at least able to print symbolic addresses. Anyway I suggest that you use the approach I described above. |