frontend segfault when switching resolutions for playback

[George Nassas <gnassas@…>]

I have my frontend setup to use different resolutions for the menus and video. Menus are at 1280x720. This crash is happening when I try to watch a show which is 1920x1080 but I also get a crash when I start a 720x480 show. Recordings which are 1280x720 play with no problem. If I turn off the resolution switching for playback then things are fine.

Environment is a core2duo machine, debian 64 lenny, 2.6.22 kernel, mesa 7.0.2, intel video driver 2.2.0, myth svn 14747, open gl on for menus (MePoWide theme), opengl sync, xv-blit for rendering.

Regular and full backtraces are attached as well as the gdb session. The crash is happening at the bindContext call here:

static Bool BindContextWrapper( Display *dpy, GLXContext gc,

GLXDrawable draw, GLXDrawable read )

{

return (*gc->driContext.bindContext)(dpy, gc->screen, draw, read,

& gc->driContext);

}

print *gc shows:

$7 = {buf = 0x2aaab2c80010 "", pc = 0x2aaab2c80010 "", limit = 0x2aaab2cbff48 "", bufEnd = 0x2aaab2cc0004 "", bufSize = 262132, xid = 12582918, share_xid = 0, vid = 37, screen = 0, imported = 0 '\0', currentContextTag = 4294967295, renderMode = 7168, feedbackBuf = 0x0, selectBuf = 0x0, fastImageUnpack = 0 '\0', fillImage = 0x2b7cd600cf30 <glFillImage>, attributes = {stack = {0x0 <repeats 16 times>}, stackPointer = 0x9a36c0}, error = 0, isDirect = 1, currentDpy = 0x849940, currentDrawable = 12582920, vendor = 0x0, renderer = 0x0, version = 0x0, extensions = 0x0, createDpy = 0x849940, maxSmallRenderCommandSize = 4096, majorOpcode = 143, driContext = {destroyContext = 0x2aaaacc4dec0, private = 0x9a8f00, mode = 0x9a0e30, bindContext = 0x2aaaacc4e680, unbindContext = 0x2aaaacc4df90}, fbconfigID = 37, currentReadable = 12582920, client_state_private = 0x9a3800, renderType = 0, server_major = 0, server_minor = 0, gl_extension_bits = '\0' <repeats 15 times>}

which shows the same bindContext address I got when I printed the initial gc context created at the frontend's startup:

$4 = {destroyContext = 0x2aaaacc4dec0 <driDestroyContext>, private = 0x0, mode = 0x0, bindContext = 0x2aaaacc4e680 <driBindContext>, unbindContext = 0x2aaaacc4df90 <driUnbindContext>}

however, my breakpoint in driCreateNewContext (which assigns bindContext) did not trip between pressing to start the program and the crash. It did trip during myth startup. There's also this suspicious note from gdb directly before the crash:

warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/dri/i915_dri.so"

Hopefully that's not a red herring.

It's possible that the root cause is also responsible for #4156.

If there's other information that would be helpful please ask. I'm set up for debugging and will continue doing that but I'm hoping someone will have an insight as I'm not very familiar with this area.

[George Nassas <gnassas@…>]

This ticket can be closed, I've traced it to a mesa bug and I'll persue it further over there.

For anyone keeping score at home various myth threads open and close the display for local queries. Inside X11 this eventually works its way down to dri_glx.c::OpenDriver which dlopen's the correct .so on the first call. Subsequent calls get the handle from that initial dlopen.

Unfortunately this doesn't increment the reference count for the .so and a dlclose at the first nested XOpenDisplay/XCloseDisplay (like in libmythtv's get_glx_version) causes the dri library to be unloaded and soon after that MythTV go boom. The unload message in the initial report turned out to be the key, something I realized moments after submitting the bug.

The quick fix, and this is Linux-specific, is to tweak the inital search at the top of OpenDriver in mesa's dri_glx.c. The match should change from:

      if (strcmp(driver->name, driverName) == 0) {
         /* found it */
         return driver;
      }

to

      if (strcmp(driver->name, driverName) == 0) {
         /* found it */
         char *libPath = ((struct link_map *)(driver->handle))->l_name;
         dlopen(libPath, RTLD_NOW | RTLD_GLOBAL);
         return driver;
      }

make sure you #include <link.h> at the top.

[Mario Limonciello <superm1@…>]

FYI: this bug has been brought upstream to mesa for those keeping score: ​https://bugs.freedesktop.org/show_bug.cgi?id=14675