Bug 111236 - VA-API radeonsi SIGSEGV __memmove_avx_unaligned
Summary: VA-API radeonsi SIGSEGV __memmove_avx_unaligned
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 19.1
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-27 22:55 UTC by KJ Liew
Modified: 2019-09-17 05:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
si_video_buffer_create fixups (1.55 KB, patch)
2019-08-26 16:34 UTC, Michel Dänzer
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description KJ Liew 2019-07-27 22:55:29 UTC
Hardware: Ryzen 2500U Mobile APU Vega 8
OS: ArchLinux 5.2.3-arch1-1-ARCH
GUI: GNOME/Wayland

$ gst-play-1.0 /path/to/H264.mp4 
Press 'k' to see a list of keyboard shortcuts.
Now playing /home/kliew/Videos/Dark Phoenix.mp4
mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the -global-isel-abort option: may only occur zero or one times!
Redistribute latency...
Redistribute latency...
Segmentation fault (core dumped)


Thread 4 "multiqueue0:src" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5cc3700 (LWP 4886)]
0x00007ffff7f42c05 in __memmove_avx_unaligned () from /usr/lib/libc.so.6
(gdb) disas
Dump of assembler code for function __memmove_avx_unaligned:
   0x00007ffff7f42be0 <+0>:	endbr64 
   0x00007ffff7f42be4 <+4>:	mov    rax,rdi
   0x00007ffff7f42be7 <+7>:	cmp    rdx,0x20
   0x00007ffff7f42beb <+11>:	jb     0x7ffff7f42ca6 <__memmove_avx_unaligned_erms+86>
   0x00007ffff7f42bf1 <+17>:	cmp    rdx,0x40
   0x00007ffff7f42bf5 <+21>:	ja     0x7ffff7f42d13 <__memmove_avx_unaligned_erms+195>
   0x00007ffff7f42bfb <+27>:	vmovdqu ymm0,YMMWORD PTR [rsi]
   0x00007ffff7f42bff <+31>:	vmovdqu ymm1,YMMWORD PTR [rsi+rdx*1-0x20]
=> 0x00007ffff7f42c05 <+37>:	vmovdqu YMMWORD PTR [rdi],ymm0
   0x00007ffff7f42c09 <+41>:	vmovdqu YMMWORD PTR [rdi+rdx*1-0x20],ymm1
   0x00007ffff7f42c0f <+47>:	vzeroupper 
   0x00007ffff7f42c12 <+50>:	ret    
End of assembler dump.
(gdb) bt
#0  0x00007ffff7f42c05 in __memmove_avx_unaligned () from /usr/lib/libc.so.6
#1  0x00007fffda85d3e3 in ?? () from /usr/lib/dri/radeonsi_dri.so
#2  0x00007fffda85d4f7 in ?? () from /usr/lib/dri/radeonsi_dri.so
#3  0x00007fffdb108133 in ?? () from /usr/lib/dri/radeonsi_dri.so
#4  0x00007fffe77a4903 in ?? () from /usr/lib/dri/radeonsi_drv_video.so
#5  0x00007ffff4976ffd in vaPutImage () from /usr/lib/libva.so.2
#6  0x00007ffff49f4c1e in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#7  0x00007ffff4a2ecf3 in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#8  0x00007ffff4a2f2bf in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#9  0x00007ffff4a2703b in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#10 0x00007ffff782fe53 in ?? () from /usr/lib/libgstbase-1.0.so.0
#11 0x00007ffff7835ee1 in ?? () from /usr/lib/libgstbase-1.0.so.0
#12 0x00007ffff7a3bcca in gst_pad_query () from /usr/lib/libgstreamer-1.0.so.0
#13 0x00007ffff7a3c3de in gst_pad_peer_query () from /usr/lib/libgstreamer-1.0.so.0
#14 0x00007ffff7a0a887 in gst_pad_peer_query_caps () from /usr/lib/libgstreamer-1.0.so.0
#15 0x00007ffff7835cd1 in ?? () from /usr/lib/libgstbase-1.0.so.0
Comment 1 Andre Klapper 2019-07-27 23:27:54 UTC
Can you please compile with debug symbols and provide an updated stacktrace?
Comment 2 Ilia Mirkin 2019-07-27 23:37:04 UTC
(In reply to Andre Klapper from comment #1)
> Can you please compile with debug symbols and provide an updated stacktrace?

Why bother? Isn't the issue pretty obvious? mesa calls memcpy, libc thinks that it's ok to use avx, but apparently it isn't...
Comment 3 Ilia Mirkin 2019-07-27 23:38:34 UTC
(In reply to Ilia Mirkin from comment #2)
> (In reply to Andre Klapper from comment #1)
> > Can you please compile with debug symbols and provide an updated stacktrace?
> 
> Why bother? Isn't the issue pretty obvious? mesa calls memcpy, libc thinks
> that it's ok to use avx, but apparently it isn't...

Or maybe that's totally not it actually - sigsegv, not sigill. Ignore that. Yes, stacktrace is absolutely required here.
Comment 4 KJ Liew 2019-07-28 03:47:34 UTC
The ArchLinux build does have symbols. When I used my own build (b_ndebug=if-release), I got better details on vaPutImage() with more detailed args, but still nothing from radeonsi_dri.so.

Did you actually mean debug info or debug symbols? Anyway, I kicked off a debug build. (buildtype=debug)
Comment 5 KJ Liew 2019-07-28 04:04:55 UTC
Here's the gdb stack-trace with debug build. If you need the same test video clip, this is what I used
Test h264 clip:
$ youtube-dl -f mp4 https://www.youtube.com/watch?v=azvR__GRQic

Thread 4 "multiqueue0:src" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5cc3700 (LWP 2173)]
0x00007ffff7f42c05 in __memmove_avx_unaligned () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7f42c05 in __memmove_avx_unaligned () from /usr/lib/libc.so.6
#1  0x00007fffda0ce432 in util_copy_rect (dst=0x7ffff53e6000 "_base_parse_set_passthrough", format=PIPE_FORMAT_R8_UNORM, dst_stride=0x100, 
    dst_x=0x0, dst_y=0x0, width=0x20, height=0x20, src=0x7fffec07d850 "", src_stride=0x20, src_x=0x0, src_y=0x0)
    at ../mesa-19.1.3/src/gallium/auxiliary/util/u_surface.c:105
#2  0x00007fffda0ce4c6 in util_copy_box (dst=0x7ffff53e6000 "_base_parse_set_passthrough", format=PIPE_FORMAT_R8_UNORM, dst_stride=0x100, 
    dst_slice_stride=0x2000, dst_x=0x0, dst_y=0x0, dst_z=0x0, width=0x20, height=0x20, depth=0x1, src=0x7fffec07d850 "", src_stride=0x20, 
    src_slice_stride=0x0, src_x=0x0, src_y=0x0, src_z=0x0) at ../mesa-19.1.3/src/gallium/auxiliary/util/u_surface.c:131
#3  0x00007fffdad7d8f5 in u_default_texture_subdata (pipe=0x7fffe82ff760, resource=0x7fffec073f20, level=0x0, usage=0x102, box=0x7ffff5cc1550, 
    data=0x7fffec07d850, stride=0x20, layer_stride=0x0) at ../mesa-19.1.3/src/gallium/auxiliary/util/u_transfer.c:67
#4  0x00007fffe74b7c56 in vlVaPutImage (ctx=0x7fffe82f2400, surface=0xc, image=0xd, src_x=0x0, src_y=0x0, src_width=0x40, src_height=0x40, 
    dest_x=0x0, dest_y=0x0, dest_width=0x40, dest_height=0x40) at ../mesa-19.1.3/src/gallium/state_trackers/va/image.c:607
#5  0x00007ffff4976ffd in vaPutImage () from /usr/lib/libva.so.2
#6  0x00007ffff49f4c1e in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#7  0x00007ffff4a2ecf3 in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#8  0x00007ffff4a2f2bf in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#9  0x00007ffff4a2703b in ?? () from /usr/lib/gstreamer-1.0/libgstvaapi.so
#10 0x00007ffff782fe53 in ?? () from /usr/lib/libgstbase-1.0.so.0
#11 0x00007ffff7835ee1 in ?? () from /usr/lib/libgstbase-1.0.so.0
#12 0x00007ffff7a3bcca in gst_pad_query () from /usr/lib/libgstreamer-1.0.so.0
#13 0x00007ffff7a3c3de in gst_pad_peer_query () from /usr/lib/libgstreamer-1.0.so.0
#14 0x00007ffff7a0a887 in gst_pad_peer_query_caps () from /usr/lib/libgstreamer-1.0.so.0
#15 0x00007ffff7835cd1 in ?? () from /usr/lib/libgstbase-1.0.so.0
Comment 7 Michel Dänzer 2019-08-26 09:35:34 UTC
(In reply to Julien Isorce from comment #6)
> It is working fine with mesa 18.3.6 [...]

I tried to bisect based on this premise, but I can reproduce the crash (with totem) even with 18.3.6. Maybe this isn't a Mesa regression.
Comment 8 Michel Dänzer 2019-08-26 16:34:02 UTC
Created attachment 145171 [details] [review]
si_video_buffer_create fixups

I've traced this to the si_video_buffer_create function, which makes multiple pipe_resources use the same buffer, but doesn't update the bo_size or make sure si_can_invalidate_texture returns false for those resources. So si_texture_transfer_map may allocate a new buffer of the original bo_size, which is smaller than the combined size of the resources => its CPU mapping doesn't always cover the calculated address.

This quick'n'dirty patch prevents the crash, but now totem just hangs for me.
Comment 9 Julien Isorce 2019-09-06 16:27:17 UTC
Hi Michel, nice catch! 

Instead of using totem which has other issues can you try:

gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec ! vaapipostproc ! videoconvert ! ximagesink 

(with and without vaapipostproc)

Thx!
Comment 10 Michel Dänzer 2019-09-06 17:04:36 UTC
(In reply to Julien Isorce from comment #9)
> gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse !
> vaapih264dec ! vaapipostproc ! videoconvert ! ximagesink 
> 
> (with and without vaapipostproc)

With vaapipostproc, it crashes without the attached patch, but works with it.
Comment 11 Julien Isorce 2019-09-07 04:39:13 UTC
Hi Michel, I confirm the attached patch fixes the issues for me too.
Comment 12 Víctor Jáquez 2019-09-09 07:12:26 UTC
Hi Michel, 

The patch also worked for me! :) Thanks!

In the case of totem, there's a work in progress https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/122 but it requires a lot more work.
Comment 13 Michel Dänzer 2019-09-09 09:09:33 UTC
Note that my patch is just a proof of concept pointing at where the issue lies. I hope it helps someone else come up with a proper fix.
Comment 14 Víctor Jáquez 2019-09-10 12:39:32 UTC
(In reply to Michel Dänzer from comment #13)
> Note that my patch is just a proof of concept pointing at where the issue
> lies. I hope it helps someone else come up with a proper fix.

:(

Who could review/improve this patch? 

Or perhaps just be bold and open a MR in gitlab or send it to mesa's mailing list? O:)


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.