Can you please compile with debug symbols and provide an updated stacktrace?

(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...

(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.

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)

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

Looks similar to https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/142

It is working fine with mesa 18.3.6 and st/va has not changed in 19.1: https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/state_trackers/va?h=19.1 

So the issues could be due to the recent changes in drivers/radeon, drivers/radeonsi or winsys/amdgpu, i.e. :

https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/drivers/radeon?h=19.1

https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/drivers/radeonsi?h=19.1

https://cgit.freedesktop.org/mesa/mesa/log/src/gallium/winsys/amdgpu?h=19.1

(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.

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.

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!

(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.

Hi Michel, I confirm the attached patch fixes the issues for me too.

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.

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.

(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:)

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2005

-- 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/1421.