GNOME Bugzilla – Bug 797007
Warning log printed when running glvideomixer command
Last modified: 2018-11-03 12:47:42 UTC
Reproduce steps: 1. Boot up the system; 2. Run below command: $ gst-launch-1.0 glvideomixer background=2 name=m sink_1::xpos=200 sink_1::ypos=200 sink_2::xpos=400 sink_2::ypos=400 sink_2::alpha=0.5 ! glimagesink sync=false uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m. uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m. uridecodebin uri=file:///mnt/src/H264Dec/Conformance/Resolution/H264_BP12_320x240_25_384_MP3_48_320_2.avi ! m. Actual result: Below warning log print but image showed correctly (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1' (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2' Actual result: Below warning log print but image showed correctly (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1' (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2' Log: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"(GstGLDisplayWayland)\ gldisplaywayland0"; ====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ====== Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57 file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1 ====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ====== Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57 file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1 ====== AIUR: 4.4.3 build on Aug 4 2018 10:38:52. ====== Core: AVI_PARSER_03.05.29 build on Aug 31 2017 09:15:57 file: /usr/lib/imx-mm/parser/lib_avi_parser_arm_elinux.so.3.1 ------------------------ ------------------------ Track 00 [video_0] Enabled ------------------------ Track 00 [video_0] Enabled Duration: 0:01:22.200000000 Duration: 0:01:22.200000000 Track 00 [video_0] Enabled Language: und Duration: 0:01:22.200000000 Language: und Mime: video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1 Mime: video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1 Language: und ------------------------ Mime: video/x-h264, parsed=(boolean)true, alignment=(string)au, stream-format=(string)byte-stream, width=(int)320, height=(int)240, framerate=(fraction)25/1 ------------------------ ------------------------ ====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ====== ====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ====== ====== VPUDEC: 4.4.3 build on Aug 4 2018 10:39:18. ====== wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40) wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40) wrapper: 3.0.0 (VPUWRAPPER_ARM64_LINUX Build on Aug 4 2018 10:20:40) vpulib: 1.1.1 firmware: 1.1.1.65535 vpulib: 1.1.1 vpulib: 1.1.1 firmware: 1.1.1.65535 firmware: 1.1.1.65535 ------------------------ ------------------------ Track 01 [audio_0] Enabled ------------------------ Track 01 [audio_0] Enabled Track 01 [audio_0] Enabled Duration: 0:01:22.248000000 Duration: 0:01:22.248000000 Language: und Language: und Duration: 0:01:22.248000000 Mime: audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000 Language: und Mime: audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000 ------------------------ Mime: audio/mpeg, mpegversion=(int)1, channels=(int)2, rate=(int)48000, bitrate=(int)320000 ------------------------ ------------------------ ====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ====== Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25 file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3 ====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ====== Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25 file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3 CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45. CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45. ====== BEEP: 4.4.3 build on Aug 4 2018 10:38:59. ====== Core: MP3 decoder Wrapper build on Jan 11 2018 10:20:25 file: /usr/lib/imx-mm/audio-codec/wrap/lib_mp3d_wrap_arm_elinux.so.3 CODEC: BLN_MAD-MMCODECS_MP3D_ARM_02.13.01_ARMV8 build on Jan 11 2018 10:05:45. (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '1' (gst-launch-1.0:6066): GLib-GObject-WARNING **: ../../glib-2.52.3/gobject/gsignal.c:2641: instance '0x35aee0a0' has no handler with id '2' Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:41.116603250 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Total showed frames (2057), playing for (0:00:41.118146125), fps (50.027). Freeing pipeline ...
Created attachment 373424 [details] [review] Check whether g_signal_handler_is_connected() as well as deal with the mutiple thread situation. The patch is the solution provided for the submitted bug.
Review of attachment 373424 [details] [review]: ::: gst/parse/grammar.y @@ +310,3 @@ } +pthread_mutex_t mutex; Use the GLib mutex API here. PThread does not exist everywhere @@ +345,3 @@ + pthread_mutex_lock(&mutex); + if (g_signal_handler_is_connected (child_proxy, set->signal_id)) { + g_signal_handler_disconnect (child_proxy, set->signal_id); From where was it otherwise disconnected before? From which code, where was it called from and why from different threads? Should we maybe simply set signal_id to 0 after disconnecting and checking for that (and protect it with a mutex)?
(In reply to Sebastian Dröge (slomo) from comment #2) When the command in reproduce steps is executed, all three video will start playing on the same board simultaneously. It can be regarded as multiple thread from here. I tried the method you provided to simply set signal_id to 0 after disconnecting, then the CRITICAL log "(gst-launch-1.0:7428): GLib-GObject-CRITICAL **: g_signal_handler_disconnect: assertion 'handler_id > 0' failed. "appears. If not to check g_signal_handler_is_connected or not to use mutex, and simply to execute g_signal_handler_disconnect, the warning log is still printed.
-- 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/gstreamer/gstreamer/issues/306.