totem never starts

[fabrice]

Totem won't start. The process shows up but the window never appears. If I start
totem using "strace totem" it ends up showing "futex(0x81f42a0, FUTEX_WAIT, 2,
NULL" and waits forever. If I start it using "strace -o totem.log totem" it
starts fine so this looks like a racing condition. I have this issue with both
totem-xine and totem-gstreamer. I'm running breezy with all packages up to date.

[Sebastien Bacher (seb128)]

Thanks for your bug. Can you get a backtrace of the hang with gdb?
- gdb totem
(gdb) run
... hang ... <Ctrl-C>
(gdb) thread apply all bt

[fabrice (fabrice-rousselle)]

Created an attachment (id=2975)
log of running totem through gdb

I removed most of (no debugging symbols found) messages and replaced them with
[...]

[Sebastien Bacher (seb128)]

thanks for the backtrace. I'm not sure of what could make that, the gstreamer
and xine backends are really differents ... maybe an xorg issue

[Stian Jordet (stian-web)]

Maybe not very helpful, but I have the same problem. Other gstreamer and xine
applications works just fine.

[Sebastien Bacher (seb128)]

I've uploaded a new version of totem (1.1.3), do you still have this issue with it?

[fabrice (fabrice-rousselle)]

(In reply to comment #5)
> I've uploaded a new version of totem (1.1.3), do you still have this issue
with it?

Yes, the behavior is exactly the same as before.

[Allison Karlitskaya (desrt)]

"me too".

Bastien says that this is some problem caused by using XThreads and GTK at the
same time and blames X.

I'll try and hammer out a small test program that locks on startup.

[Allison Karlitskaya (desrt)]

Created an attachment (id=3044)
sample program

This program locks up for me depending on how I compile it.

The flag inside the gthread-2.0 pkg-config stuff that appears to cause the
problem is '-pthread'.

[Allison Karlitskaya (desrt)]

In case you guys can't reproduce this on your end, here's a trace with debugging
symbols from breezy... It appears that the deadlock occurs while initialising
the MIT-SHM extension.

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7840e0e in __lll_mutex_lock_wait ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb783dd95 in _L_mutex_lock_33 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb76f5d6e in ?? () from /usr/lib/libXext.so.6
#4 0xb76f5178 in ?? () from /usr/lib/libXext.so.6
#5 0xb76f45b8 in ?? () from /usr/lib/libXext.so.6
#6 0x00000025 in ?? ()
#7 0xb76ad098 in ?? ()
#8 0xb79b0778 in ?? () from /usr/lib/libX11.so.6
#9 0x08058c98 in ?? ()
#10 0x0807fdd8 in ?? ()
#11 0xbfb7c478 in ?? ()
#12 0xb790f59b in _XLockDisplay (dpy=0x8056b00) at ../../src/locking.c:481
#13 0xb790f59b in _XLockDisplay (dpy=0x8058c98) at ../../src/locking.c:481
#14 0xb78fcb36 in XQueryExtension (dpy=0x8058c98, name=0xb76feaff "MIT-SHM",
    major_opcode=0xfffffffc, first_event=0xfffffffc, first_error=0xfffffffc)
    at ../../src/QuExt.c:46
#15 0xb78f257b in XInitExtension (dpy=0x8058c98, name=0xb76feaff "MIT-SHM")
    at ../../src/InitExt.c:49
#16 0xb76fe61b in XextAddDisplay (extinfo=0xb76ff6c0, dpy=0x8058c98,
    ext_name=0xfffffffc <Address 0xfffffffc out of bounds>, hooks=0xb76ff4c0,
    nevents=1, data=0xfffffffc <Address 0xfffffffc out of bounds>)
---Type <return> to continue, or q <return> to quit---
    at ../../src/extutil.c:108
#17 0xb76faa90 in find_display (dpy=0x8058c98) at ../../src/XShm.c:80
#18 0xb76face0 in XShmQueryExtension (dpy=0xfffffffc) at ../../src/XShm.c:149
#19 0xb7c15e88 in _gdk_windowing_image_init ()
   from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb7c00669 in gdk_display_open () from /usr/lib/libgdk-x11-2.0.so.0
#21 0xb7be0f03 in gdk_display_open_default_libgtk_only ()
   from /usr/lib/libgdk-x11-2.0.so.0
#22 0xb7d89da5 in gtk_init_check () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7d89dd8 in gtk_init () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x08048665 in main ()

[Allison Karlitskaya (desrt)]

The problem is as follows:

These two calls happen to pthread_mutex_lock() without an unlock call inbetween.

Breakpoint 3, 0xb77fdc42 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libpthread.so.0
(gdb) bt
#0 0xb77fdc42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#1 0xb784a5e7 in _XInternalLockDisplay (dpy=0x8058c98, wskip=32) at
../../src/locking.c:506
#2 0xb7841c42 in _XWaitForReadable (dpy=0x8058c98) at ../../src/XlibInt.c:504
#3 0xb7842072 in _XRead (dpy=0x8058c98, data=0xbfb3893c
"\027G\uffff\uffff\uffffNk\uffff\204\uffff\uffff\uffffP\uffff\005\b\230\214\005\b\uffff\211\uffff\uffff0\v\uffff\uffff\001",
size=32)
    at ../../src/XlibInt.c:1080
#4 0xb7842fe8 in _XReply (dpy=0x8058c98, rep=0xbfb3893c, extra=0, discard=0) at
../../src/XlibInt.c:1712
#5 0xb76bada2 in XShmQueryVersion (dpy=0x8058c98, majorVersion=0x8056c50,
minorVersion=0x8056c50, sharedPixmaps=0x8056c50)
    at ../../src/XShm.c:189
#6 0xb7bd1eb8 in _gdk_windowing_image_init (display=0x805d950) at
gdkimage-x11.c:211
#7 0xb7bbc669 in IA__gdk_display_open (display_name=0x8056c50 "") at
gdkdisplay-x11.c:312
#8 0xb7b9cf03 in IA__gdk_display_open_default_libgtk_only () at gdk.c:272
#9 0xb7d45da5 in IA__gtk_init_check (argc=0x8056c50, argv=0x8056c50) at
gtkmain.c:713
#10 0xb7d45dd8 in IA__gtk_init (argc=0x8056c50, argv=0x8056c50) at
gtkmain.c:748#11 0x08048655 in main ()
(gdb) c
Continuing.

Breakpoint 3, 0xb77fdc42 in pthread_mutex_lock () from
/lib/tls/i686/cmov/libpthread.so.0
(gdb) bt
#0 0xb77fdc42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#1 0xb784a59b in _XLockDisplay (dpy=0x8058c98) at ../../src/locking.c:481
#2 0xb7837b36 in XQueryExtension (dpy=0x8058c98, name=0xb7c07883
"XInputExtension", major_opcode=0x8056c50,
    first_event=0x8056c50, first_error=0x8056c50) at ../../src/QuExt.c:46
#3 0xb7be8bd5 in _gdk_input_common_init (display=0x805d950, include_core=0) at
gdkinput-x11.c:394
#4 0xb7be9ce9 in _gdk_input_init (display=0x805d950) at gdkinput-xfree.c:41
#5 0xb7bbc67f in IA__gdk_display_open (display_name=0x8056c50 "\001") at
gdkdisplay-x11.c:314
#6 0xb7b9cf03 in IA__gdk_display_open_default_libgtk_only () at gdk.c:272
#7 0xb7d45da5 in IA__gtk_init_check (argc=0x8056c50, argv=0x8056c50) at
gtkmain.c:713
#8 0xb7d45dd8 in IA__gtk_init (argc=0x8056c50, argv=0x8056c50) at
gtkmain.c:748#9 0x08048655 in main ()

This is caused by the fact that _XReply and friends assume that the X display is
already locked and do things like this:

  Unlock( dpy ); <-- does nothing if not already locked.
  poll();
  Lock( dpy );

So even if the display wasn't locked when _XReply was invoked, it will be locked
when it returns. XShmQueryVersion appears to know this and makes the proper
locking calls on entry and the proper unlocking calls on exit. However, in the
version of the library that I have installed, the calls are never made. I can't
explain this.

Here's a dump of the assembly for the XShmQueryVersion that I have installed
right now

d4383d697f04ef43e93c5e1752e107bd usr/lib/libXext.so.6.4.1 from libxext6
version 1:6.4.3-2

00006d21 <XShmQueryVersion>:
    6d21: 55 push %ebp
    6d22: ...

[Allison Karlitskaya (desrt)]

Problem has been resolved by last night's libxext6 upload. Thanks, Daniel.