i.MX 8M Mini set GST_DEBUG=5 cause gst-launch crash

[shengfazhang]

Hi, I encountered a wired problem when develop gstreamer app on i.MX 8M Mini.

If I enable GST_DEBUG=5 cause gst-launch-1.0 cash. Caused by too small stack size?

The command as followed:

GST_DEBUG=5 gst-launch-1.0 -e v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, format=YUY2, width=1280,height=720, framerate=30/1 ! tee name=t ! queue ! vpuenc_h264 ! queue ! h264parse ! qtmux ! filesink location=5640_h264.mp4 t. ! queue ! waylandsink

The output:

====== VPUENC: 4.4.4 build on Jun 21 2019 06:49:10. ======
	wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Jun 20 2019 10:35:13)
	vpulib: 1.1.1
	firmware: 1.1.1.65535
Caught SIGSEGV
#0  0x0000ffffa5b85900 in __waitpid (pid=<optimized out>, 
#1  0x0000ffffa5bc0cf8 in g_on_error_stack_trace ()
#2  0x000000000040404c in ?? ()
#3  0x0000ffffa5b6f480 in _IO_list_all () from /lib/libc.so.6
Spinning.  Please run 'gdb gst-launch-1.0 3669' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

gdb gst-launch-1.0 3669 output:

Attaching to program: /usr/bin/gst-launch-1.0, process 3669
[New LWP 3670]
[New LWP 3671]
[New LWP 3672]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
0x0000ffffa5b851c8 in __GI___nanosleep (requested_time=0xfffffde02a90, remaining=0xfffffde02aa0) at /usr/src/debug/glibc/2.27-r0/git/sysdeps/unix/sysv/linux/nanosleep.c:28

warning: Source file is more recent than executable.
28	  return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) bt full
#0  0x0000ffffa5b851c8 in __GI___nanosleep (requested_time=0xfffffde02a90, remaining=0xfffffde02aa0) at /usr/src/debug/glibc/2.27-r0/git/sysdeps/unix/sysv/linux/nanosleep.c:28
        _x0tmp = 281474941069968
        _x0 = 281474941069968
        _x8 = 101
        _x1tmp = 281474941069984
        _x1 = 281474941069984
        _sys_result = <optimized out>
        _sys_result = <optimized out>
        sc_cancel_oldtype = 0
#1  0x0000ffffa5c16924 in g_usleep () from /usr/lib/libglib-2.0.so.0
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Zhiming_Liu]

Did you try to use smaller framesize like(640*480)?

[shengfazhang]

Hi, @Zhiming_Liu 

I finally found the crash is caused by VPU!

When I run the following command, everything is OK. And the VPU is not involved!

GST_DEBUG=5 gst-launch-1.0 -e v4l2src device=/dev/video1 io-mode=2 ! image/jpeg,format=MJPEG,width=640,height=480,framerate=30/1 ! jpegdec ! waylandsink

And If I run the following command, it crashed as VPU decode H264!

GST_DEBUG=5 gst-play 5640_h264.mp4

0:00:00.896865250 3716 0xffff941ee0f0 DEBUG GST_BUS gstbus.c:353:gst_bus_post:<bus4> [msg 0xffff8c0188a0] dropped
0:00:00.896910000 3716 0xffff941ee0f0 DEBUG GST_STATES gstelement.c:2827:gst_element_set_state_func:<vpudec0> set_state to PAUSED
0:00:00.896933000 3716 0xffff941ee0f0 DEBUG GST_STATES gstelement.c:2852:gst_element_set_state_func:<vpudec0> setting target state to PAUSED
0:00:00.896953500 3716 0xffff941ee0f0 DEBUG GST_STATES gstelement.c:2865:gst_element_set_state_func:<vpudec0> current READY, old_pending VOID_PENDING, next VOID_PENDING, old return SUCCESS
0:00:00.896978250 3716 0xffff941ee0f0 DEBUG GST_STATES gstelement.c:2899:gst_element_set_state_func:<vpudec0> final: setting state from READY to PAUSED
0:00:00.897008375 3716 0xffff941ee0f0 DEBUG videodecoder gstvideodecoder.c:2010:gst_video_decoder_reset:<vpudec0> reset full 1
====== VPUDEC: 4.4.4 build on Jun 21 2019 06:49:10. ======
wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Jun 20 2019 10:35:13)
vpulib: 1.1.1
firmware: 1.1.1.65535
Segmentation fault ------------- After VPUDEC, it crashed!

[Zhiming_Liu]

Yes, i tried. If i don't set GST_DEBUG=4/5,the command you shared would work.The GST_DEBUG=2/3 can work.

[shengfazhang]

And I reproduce on Linux imx8mmevk 5.10.72-lts-5.10.y+ga68e31b63f86 with the following command:

GST_DEBUG=5 gst-launch-1.0 filesrc location=/run/media/sda1/5640_h264.mp4 typefind=true ! h264parse ! vpudec ! fakesink

Log and coredump are attached.

[shengfazhang]

Is there any suggestion?