Bug 82517 - [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player
Summary: [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when clo...
Status: CLOSED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-12 16:04 UTC by Kai
Modified: 2014-08-15 09:40 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
GDB backtrace of the crash in the VDPAU module (12.26 KB, text/plain)
2014-08-12 16:04 UTC, Kai 		Details
VDPAU_TRACE of the crash. (16.00 KB, text/plain)
2014-08-12 17:53 UTC, Kai 		Details
Full VDPAU trace and no crash, when a YouTube video is running in the background (2.68 MB, text/plain)
2014-08-12 18:37 UTC, Kai 		Details
Possible fix. (9.30 KB, patch)
2014-08-13 13:59 UTC, Christian König 		Details | Splinter Review
View All

Description Kai 2014-08-12 16:04:42 UTC 
Created attachment 104510 [details]
GDB backtrace of the crash in the VDPAU module

This is NOT bug 82428, I have the patch from attachment 104443 [details] [review] applied!

When closing a tab in a browser (Iceweasel/Firefox 31 in my case), that contains a Flash video player, that uses VDPAU for accelerated playback, I see the following crash:

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007f76ed331f57 in map_msg_fb_buf (dec=0x7f76fa66b6f0) at ../../../../../../src/gallium/drivers/radeon/radeon_uvd.c:125
> 125             ptr = dec->ws->buffer_map(buf->cs_handle, dec->cs, PIPE_TRANSFER_WRITE);

This takes the plugin-container process down with it. Which means it's mostly annoying.

The attached file contains a full backtrace with GDB attached to the plugin-container process.


My stack is (base: Debian Testing):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Linux: Git:~agdf5/linux:drm-next-3.17-rebased-on-fixes:fa78380797 (calls itself 3.16-rc6)
Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz>
> 9e05820da42549ce9c89d147cf1f8e19  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_ce.bin
> c8bab593090fc54f239c8d7596c8d846  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_mc.bin
> 3618dbb955d8a84970e262bb2e6d2a16  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_me.bin
> c000b0fc9ff6582145f66504b0ec9597  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_mec.bin
> 0643ad24b3beff2214cce533e094c1b7  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_pfp.bin
> ba6054b7d78184a74602fd81607e1386  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_rlc.bin
> 11288f635737331b69de9ee82fe04898  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_sdma.bin
> 284429675a5560e0fad42aa982965fc2  /lib/firmware/updates/3.16.0-rc6-citadel/radeon/hawaii_smc.bin
libdrm: 2.4.56-1
LLVM: SVN:trunk/r215347 (3.6 snapshot)
libclc: Git:master/5b48f170c8
Mesa: Git:master/4c16e6a8e0 + patch from attachment 104443 [details] [review]
DDX: Git:master/fbf575cb01 + patch from <http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html>
X: 2:1.16.0-1 (1.16.0)
Comment 1 Kai 2014-08-12 17:09:30 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.
Comment 2 Christian König 2014-08-12 17:30:54 UTC 
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.
Comment 3 Kai 2014-08-12 17:53:51 UTC 
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.
Comment 4 Christian König 2014-08-12 18:07:37 UTC 
(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.
Comment 5 Kai 2014-08-12 18:37:15 UTC 
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.
Comment 6 Christian König 2014-08-13 12:27:47 UTC 
(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.
Comment 7 Christian König 2014-08-13 13:59:39 UTC 
Created attachment 104563 [details] [review]
Possible fix.

That patch does the trick for me, please test.
Comment 8 Kai 2014-08-15 09:38:19 UTC 
(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.
Comment 9 Christian König 2014-08-15 09:40:15 UTC 
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.