GNOME Bugzilla – Bug 794940
SEGFAULT when running gstreamer-vaapi on ARM
Last modified: 2018-04-04 07:46:53 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.
+ Trace 238531
Thread 3041915984 (LWP 16874)
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.
Maybe try and reproduce in valgrind ?
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!