After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794940 - SEGFAULT when running gstreamer-vaapi on ARM
SEGFAULT when running gstreamer-vaapi on ARM
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
git master
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-04-03 17:35 UTC by Paul Kocialkowski
Modified: 2018-04-04 07:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paul Kocialkowski 2018-04-03 17:35:51 UTC
While bringing up VAAPI support for the VPU found on Allwinner platforms, I am hitting a segmentation fault with GStreamer.

My test pipeline is the following:
gst-launch-1.0 -v filesrc location=videos/big_buck_bunny_480p_MPEG2_MP2_25fps_1800K.MPG ! mpegpsdemux ! vaapimpeg2dec ! video/x-raw,format=NV12 ! videoconvert ! ximagesink

Note that the result is the same without the NV12 caps filter. I have tried both with xvimagesink and kmssink and the issue is present in both cases.

The SEGFAULT happens after calling libVA's DeriveImage and DestroyImage, about once every three runs of gst-launch.
When the fault happens, I sometimes see the following debug message: free(): corrupted unsorted chunks

Depending on debug options and whether it's running in GCC, it sometimes doesn't show, or shows another error related to the memory heap with malloc/realloc/free.

The backtrace in GDB is the following:

Thread 10 "mpegpsdemux0:si" received signal SIGSEGV, Segmentation fault.

Thread 3041915984 (LWP 16874)

  • #0 _int_malloc
  • #1 malloc

I have built all of GStreamer with -g (by not specifying --disable-debug at configure time).

Here is also the list of threads running at that moment:

Thread 10 "mpegpsdemux0:si" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb54ff450 (LWP 16928)]
0xb6aa9748 in _int_malloc () from /usr/lib/libc.so.6
(gdb) info thread
  Id   Target Id         Frame 
  1    Thread 0xb6ff5790 (LWP 16917) "gst-launch-1.0" 0xb6b02760 in poll () from /usr/lib/libc.so.6
  2    Thread 0xb5ec9450 (LWP 16920) "gst-launch-1.0" 0xb6b90970 in nanosleep () from /usr/lib/libpthread.so.0
  4    Thread 0xb4aff450 (LWP 16922) "gldisplay-event" 0xb6b02760 in poll () from /usr/lib/libc.so.6
  6    Thread 0xb0434450 (LWP 16924) "llvmpipe-0" 0xb6b8bdb4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  7    Thread 0xafc33450 (LWP 16925) "llvmpipe-1" 0xb6b8bdb4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  8    Thread 0xaf2ff450 (LWP 16926) "llvmpipe-2" 0xb6b8bdb4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
  9    Thread 0xae8ff450 (LWP 16927) "llvmpipe-3" 0xb6b8bdb4 in pthread_cond_wait@@GLIBC_2.4 () from /usr/lib/libpthread.so.0
* 10   Thread 0xb54ff450 (LWP 16928) "mpegpsdemux0:si" 0xb6aa9748 in _int_malloc () from /usr/lib/libc.so.6
  11   Thread 0xadaff450 (LWP 16929) "gmain" 0xb6b02760 in poll () from /usr/lib/libc.so.6

I've been investigating the issue for a while now and can't really get a grasp on what is happening here. As far as I can tell, it doesn't seem directly related to my libVA implementation. Its buffers are handled correctly and it's clear that the fault doesn't happen there.

I have tried replacing the vaapimpeg2dec element with mpeg2dec and adding mpegvideo parse into the mix (that is required for the latter), and things work fine (although the video is still laggy despite using kmssink and hardware scaling). Adding mpegvideoparse with vaapi also doesn't help.
Comment 1 Nicolas Dufresne (ndufresne) 2018-04-03 17:44:03 UTC
Maybe try and reproduce in valgrind ?
Comment 2 Paul Kocialkowski 2018-04-04 07:46:53 UTC
That's exactly what I was about to try next ;) Valgrind did confirm that it's a heap metadata corruption issue but also gave insight on where it was coming from. It turns out this was caused by the assembly routine using in our libVA backend (that was the culprit after all) to do untiling of the frames.

So no bug in gstreamer-vaapi after all!