| Summary: | Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Strangiato <bugseforuns> |
| Component: | GLX | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | viktor_jaegerskuepper |
| Version: | 19.0 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Strangiato
2019-02-05 16:43:16 UTC
This bug persists on Arch Linux after upgrade to mesa 19. Can you add attachment of dmesg when issue occurred? Thanks! James dmesg shows no error. Bug persists with mesa 19.0.2 on Arch Linux. The VLC devs could have provided more information on why they believe this is a Mesa bug. Its hard to tell because there are so many threads but it looks like maybe it gets stuck waiting in xcb_wait_for_special_event(). Could be a bug in libxcb but I'm just guessing. I was able to reproduce this, below is a better backtrace of the hanging thread. Looks like it's waiting for a Present idle event. Not sure yet if this Mesa's fault (maybe it missed the event while the context wasn't current), or maybe the X server failed to send an event when it should (e.g. because the window was unmapped). Most likely not an XCB issue though. Thread 16 (Thread 0x7f697df1f700 (LWP 9784)): #0 0x00007f69ec60eb69 in __GI___poll (fds=0x7f697df1e508, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x00007f69e8c64cf7 in () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f69e8c66a0a in xcb_wait_for_special_event () at /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f69e1088bf5 in dri3_wait_for_event_locked (draw=0x7f697432bf98) at ../src/loader/loader_dri3_helper.c:545 #4 0x00007f69e1088bf5 in dri3_wait_for_event_locked (draw=0x7f697432bf98) at ../src/loader/loader_dri3_helper.c:529 #5 0x00007f69e1088ef7 in dri3_find_back (draw=draw@entry=0x7f697432bf98) at ../src/loader/loader_dri3_helper.c:670 #6 0x00007f69e1089666 in dri3_get_buffer (format=format@entry=4098, buffer_type=buffer_type@entry=loader_dri3_buffer_back, draw=draw@entry=0x7f697432bf98, driDrawable=<optimized out>) at ../src/loader/loader_dri3_helper.c:1800 #7 0x00007f69e108a590 in loader_dri3_get_buffers (driDrawable=<optimized out>, format=4098, stamp=0x7f697431f5a0, loaderPrivate=0x7f697432bf98, buffer_mask=<optimized out>, buffers=0x7f697df1e830) at ../src/loader/loader_dri3_helper.c:2019 #8 0x00007f69c4e03de0 in dri_image_drawable_get_buffers (statts_count=<optimized out>, statts=<optimized out>, images=<optimized out>, drawable=<optimized out>) at ../src/gallium/state_trackers/dri/dri2.c:339 #9 0x00007f69c4e03de0 in dri2_allocate_textures (ctx=0x7f697431f950, drawable=0x7f697431f5a0, statts=0x7f69740504a0, statts_count=1) at ../src/gallium/state_trackers/dri/dri2.c:466 #10 0x00007f69c4e05f72 in dri_st_framebuffer_validate (stctx=<optimized out>, stfbi=<optimized out>, statts=0x7f69740504a0, count=1, out=0x7f697df1e9a0) at ../src/gallium/state_trackers/dri/dri_drawable.c:85 #11 0x00007f69c5196117 in st_framebuffer_validate (stfb=0x7f697404ffd0, st=st@entry=0x7f697404a920) at ../src/mesa/state_tracker/st_manager.c:222 #12 0x00007f69c5196456 in st_api_make_current (stapi=<optimized out>, stctxi=0x7f697404a920, stdrawi=0x7f697431f5a0, streadi=0x7f697431f5a0) at ../src/mesa/state_tracker/st_manager.c:1082 #13 0x00007f69c4e059cd in dri_make_current (cPriv=<optimized out>, driDrawPriv=<optimized out>, driReadPriv=<optimized out>) at ../src/gallium/state_trackers/dri/dri_context.c:301 #14 0x00007f69c4dffe54 in driBindContext (pcp=<optimized out>, pdp=<optimized out>, prp=<optimized out>) at ../src/mesa/drivers/dri/common/dri_util.c:579 #15 0x00007f69e107e546 in dri3_bind_context (context=0x7f697431f7b0, old=<optimized out>, draw=88080385, read=88080385) at ../src/glx/dri3_glx.c:210 #16 0x00007f69e106a684 in MakeContextCurrent (dpy=0x7f6974150740, draw=88080385, read=88080385, gc_user=0x7f697431f7b0) at ../src/glx/glxcurrent.c:220 #17 0x00007f697daa936b in () at /usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libglx_plugin.so #18 0x00007f697de14632 in () at /usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libgl_plugin.so #19 0x00007f69ec44111e in vlc_module_unload () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9 #20 0x00007f69ec490e6d in () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9 #21 0x00007f69ec4a115c in () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9 #22 0x00007f69ec494506 in () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9 #23 0x00007f69ec495dea in () at /usr/lib/x86_64-linux-gnu/libvlccore.so.9 #24 0x00007f69ec6f7fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #25 0x00007f69ec61982f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (In reply to Michel Dänzer from comment #6) > Not sure yet if this Mesa's fault (maybe it missed the event while the context > wasn't current), or maybe the X server failed to send an event when it should > (e.g. because the window was unmapped). So far I'm not seeing how either of that could be the case. > Most likely not an XCB issue though. I'm not sure about this anymore, since thread 6 (from Qt) is stuck in xcb_wait_for_event. Maybe there's some kind of bad interaction between that and xcb_wait_for_special_event. Anyway, I won't be able to investigate more for a couple of weeks at least. (In reply to Michel Dänzer from comment #7) > > [...] maybe the X server failed to send an event when it should > > (e.g. because the window was unmapped). I've now confirmed this is what's happening. VLC has already destroyed the X11 window at this point, so the X server can't send any Present events for it anymore. It might be tricky to make Mesa robust against this... While the GLX spec says this should be handled gracefully, I suspect it might be easier for VLC to destroy the GLX context before the window. > > Most likely not an XCB issue though. > > I'm not sure about this anymore, since thread 6 (from Qt) is stuck in > xcb_wait_for_event. That's using a different XCB display handle, so unrelated. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/116. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.