Xlib: unexpected async reply (sequence 0x2b)!

[Ben Dailey <ben@…>]

After the mythtv-vid merge r19417 playing back almost all recording causes the front end to hang with error: Xlib: unexpected async reply (sequence 0x2b)! from my research this is a threading issue. r19416 does not demonstrate this issue. If I run mythfrontend under gdb the lock up does not occur also running with "-v all" seems to cause the issue not occur as well. Command run is "exec /usr/bin/mythfrontend -l /var/log/mythtv/frontend.log -v important,general,playback,libav"

MythTV Version : 19417M
MythTV Branch : trunk
Library API : 0.22.20081222-1
Network Protocol : 43
QT Version : 4.4.2
Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_x11 using_xrandr using_xv using_xvmc using_xvmc_opengl using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_mheg using_xvmc_pbuffer

Attached: configure output, frontend log, and gdbcommands files I tried to use for debug. Please let me know how I can help or what other information would be helpful.

[eric.bosch@…]

I am experiencing the same thing... It is not consistent, I am having the same failure about 50% of the time, but I can't identify any specific conditions that cause it.

[danielk]

Do you have OpenGL V-Sync enabled? Does the problem go away when you disable it?

[Ben Dailey <ben@…>]

I have tried with both OpenGL V-Sync enabled and disabled in Playback settings with the same results. I haven't tried with it disabled as a configure switch. I would it be helpful to disable it before building?

[eric.bosch@…]

I have just experienced this same error during dvd playback except it was sequence 0x32

[danielk]

(In [19506]) Refs #6036. Adds X11 lock in 3 instances which were overlooked.

[danielk]

Ben, please try the latest sources before trying to disable it at compile time. I found three other problems in the code which could result in an async reply (other than the known problem when using V-Sync.) One of them would be applicable in your setup.

BTW The first log is missing at least one line of debug output. If it was cut-n-pasted from the console, it's possible the Xlib error message overwrote it, if it was logged to a file, the missing line could be a clue...

[Ben Dailey <ben@…>]

OK after much more testing and trying to come up with a reliable way to reproduce the problem I think I may have some hints or at least observations. I can confirm for with absolute certainty that the problem occurs with and with out opengl vsync turned on at run time. I was able to come up with backtraces for opengl vsync on and off. I have attached the logs and backtraces (Actual files no copy and paste). OK observations: No reliable way to reproduce, but I would startx, then launch gdb and run mythtfrontend. As soon as the frontend started I would connect via telnet and issue "jump livetv".

Every time I got the "Xlib: unexpected async reply (sequence 0x2b)!" error message and the frontend would hang the following message was always missing from the log output: "VDP: LoadBestPreferences(1920x1088, 29.97)"

Please include all output in bug reports.
MythTV Version : 19512
MythTV Branch : trunk
Library API : 0.22.20081222-1
Network Protocol : 43
QT Version : 4.4.2
Options compiled in:

linux debug using_alsa using_backend using_dvb using_frontend using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_x11 using_xrandr using_xv using_xvmc using_xvmc_opengl using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_mheg using_xvmc_pbuffer

[Mitch]

I'm facing the same errors. I haven't either found a way to easily reproduce and i need to start the frontend several times after which at some random time it will start successfully. Please let me know if there is some way to assist in debugging this. I'm not using opengl with vsync or even menu rendering.

[danielk]

debugging patch

[danielk]

Ben, can you tell me if the attached patch has any effect?

[eric.bosch@…]

Sorry to jump in here, but I've tested this patch. It does seem to eliminate the problem after several tests. I am continuing to test and will let you know if I have a recurrence of the lock.

[anonymous]

After applying the attached patch I can no longer recreate the unexpected async reply. Thanks.

[Ben Dailey <ben@…>]

Sorry that last comment was from me (Ben).

[danielk]

Another debugging patch

[danielk]

updated version

[danielk]

(In [19573]) Refs #6036. Some additional X11 locking.

[danielk]

(In [19574]) Refs #6036. Revert [19573], I'll apply more conservative version of this later.

[danielk]

(In [19575]) Refs #6036. Revert part of [19574], some extra stuff snuck in to the previous revert.

[danielk]

(In [19576]) Refs #6036. Fixes a bug spotted in gdb_v3patched.txt

[Ben Dailey <ben@…>]

unexpected async reply log

[Ben Dailey <ben@…>]

unexpected async reply backtrace

[Mitch]

Todays SVN is still facing this problems so i'm assuming these patches never went in ? I'm still using version 1 patch above succesfully as it's the easiest to apply and doesn't affect any other files when i'm doing daily SVN pulls.

[danielk]

Ben, it looks like in the latest backtrace the problem is originating within the nvidia OpenGL driver. What driver version and hardware are you using?

[danielk]

(In [19633]) Refs #6036. Removing MythApplication class, it didn't function as intended and so just acts as cruft.

[danielk]

(In [19634]) Refs #6036. Temporary fix for playback startup problem.

This slows down playback startup if you are using the Qt paint engine for MythUI hand have compiled in either opengl-video playback or opengl vsync and is an ineligant fix, but it does appear to address the X Async Reply playback startup problem for those affected.

[Ben Dailey <ben@…>]

(--) PCI:*(1:0:0) nVidia Corporation NV34 FX 5200 rev 161, Mem @ 0xfd000000/24, 0xe8000000/27, BIOS @ 0xfe9e0000/17 (II) Module glx: vendor="NVIDIA Corporation" (II) NVIDIA GLX Module 173.14.15 Fri Oct 31 16:29:34 PST 2008 (II) LoadModule: "nvidia"

I have seen no issues since changeset 19634.

Thanks, Ben