Summary: | [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player | ||
---|---|---|---|
Product: | Mesa | Reporter: | Kai <kai> |
Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
GDB backtrace of the crash in the VDPAU module
VDPAU_TRACE of the crash. Full VDPAU trace and no crash, when a YouTube video is running in the background Possible fix. |
Description
Kai
2014-08-12 16:04:42 UTC
Oh, I just found another way to trigger this: open any past broadcast on Twitch with a "t" URL parameter, ie. t=3h03m48s, appended. Apparently vlVdpDecoderDestroy get's called from Flash before jumping to the target time code as well. Can you try setting VDPAU_TRACE and VDPAU_TRACE_FILE and get me the order in which flash calls those functions? That just sounds like flash wants to use a decoder after destroying it and we don't handle that correctly. Created attachment 104514 [details] VDPAU_TRACE of the crash. (In reply to comment #2) > Can you try setting VDPAU_TRACE and VDPAU_TRACE_FILE and get me the order in > which flash calls those functions? > > That just sounds like flash wants to use a decoder after destroying it and > we don't handle that correctly. Sure, attached you find the log (I didn't find a way to just pass those variables to plugin-container, so I passed it to the parent iceweasel process). Steps to get that log: 1. Start Iceweasel (aka Firefox) with the environment variables 2. Open a Twitch broadcast at some point within 3. Observed crash 4. Closed Browser. (In reply to comment #3) > Created attachment 104514 [details] > VDPAU_TRACE of the crash. That log doesn't seems to be complete, it ends in the middle of tracing a vdp_decoder_render call. Created attachment 104518 [details] Full VDPAU trace and no crash, when a YouTube video is running in the background (In reply to comment #4) > (In reply to comment #3) > > Created attachment 104514 [details] > > VDPAU_TRACE of the crash. > > That log doesn't seems to be complete, it ends in the middle of tracing a > vdp_decoder_render call. I noticed that as well, though I forgot to mention it in my previous post, but I tried it several times and the log always ends somewhere in the middle. If you have any idea how I can capture the whole log, let me know. (Or maybe you can reproduce it on your end? Just pick one recored broadcast from Twitch, e.g. <http://www.twitch.tv/carbotanimations/b/557380266?t=1h01m> and it should segfault) Another observation I made: if you run a YouTube video in the backgrund in parallel to e.g. opening <http://www.twitch.tv/carbotanimations/b/557380266?t=1h01m>, then suddenly Flash is not crashing. I traced VDPAU with a YT video running in the background and attached the file to this post. (In reply to comment #5) > (Or maybe you can reproduce it on your end? Just pick one recored broadcast > from Twitch, e.g. > <http://www.twitch.tv/carbotanimations/b/557380266?t=1h01m> and it should > segfault) Took me a while, but I was able to reproduce the problem and take a complete log. > Another observation I made: if you run a YouTube video in the backgrund in > parallel to e.g. opening > <http://www.twitch.tv/carbotanimations/b/557380266?t=1h01m>, then suddenly > Flash is not crashing. I traced VDPAU with a YT video running in the > background and attached the file to this post. No wonder that it crashes, what flash does here is destroying the device first and then trying to destroy the decoder who depends on the device: vdp_device_destroy(1) vdp_decoder_destroy(2) Sounds like a bug in flash to me, but on the other hand the VDPAU state tracker shouldn't crash, but just return an error here. Going to take a look into the code if we can't fix that somehow. Created attachment 104563 [details] [review] Possible fix. That patch does the trick for me, please test. (In reply to comment #7) > Created attachment 104563 [details] [review] [review] > Possible fix. > > That patch does the trick for me, please test. Yes, the patch works for me as well. Thank you! Since you've already commited the patch (<http://cgit.freedesktop.org/mesa/mesa/commit/?id=6fb42ee7a632e181160ac4be234b30e50a1b91d5>) I don't think a Tested-by will be needed here anylonger. Thanks for testing, sounds like we can close this now. |
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.