GNOME Bugzilla – Bug 771773
Android: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Last modified: 2018-11-03 12:36:22 UTC
Created attachment 336008 [details] Logcat logs with GStreamer logging at highest level, including backtrace I am using a modified version of gst-player for Android: https://github.com/sdroege/gst-player/tree/master/android When starting up/playing multiple RTSP streams simultaneously a seg fault occurs sometimes resulting in the application crashing and exiting. I have attached the logcat output including the backtrace after the seg fault occurred.
Can you run addr2line on the values below and including the gst_gl_ensure_element_data stack frame please?
Created attachment 336263 [details] backtrace after ndk-stack (with *.c files and line numbers)
So, one of the arguments to strcmp is NULL.
Created attachment 336265 [details] [review] element: check for invalid gstcontext's being provided
Created attachment 336266 [details] [review] element: use g_strcmp0 in set_context
So, these will protect against the NULL context type but doesn't explain where that comes from. Are you setting GstContext's on the pipeline in your modified GstPlayer?
The only change I made was in player.c, I added these 2 lines at the end of the native_new method: pipeline = gst_player_get_pipeline(player->player); gst_pipeline_use_clock(GST_PIPELINE (pipeline), NULL); https://github.com/sdroege/gst-player/blob/master/android/app/src/main/jni/player.c This was in an effort to reduce latency as much as possible, and setting the clock to NULL did the trick. I am not explicitly setting the GstContext on the pipeline.
(In reply to mark.dion91 from comment #7) > This was in an effort to reduce latency as much as possible, and setting the > clock to NULL did the trick. This will cause lots of other problems though, especially in combination with RTSP. The clock should never introduce any latency though, unless other settings are wrong or there's a bug.This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
Oops, ignore the part at the end. Clicked on the wrong button
My first attempt at reducing the latency did not work: pipeline = gst_player_get_pipeline(player->player); gst_pipeline_set_latency(GST_PIPELINE (pipeline), 200 * GST_MSECOND); This should reduce the latency to 200ms if I understand it right, but instead it remains at the default ~2s. What's the proper way to do this?
(In reply to mark.dion91 from comment #10) > My first attempt at reducing the latency did not work: > > pipeline = gst_player_get_pipeline(player->player); > gst_pipeline_set_latency(GST_PIPELINE (pipeline), 200 * GST_MSECOND); > > This should reduce the latency to 200ms if I understand it right, but > instead it remains at the default ~2s. What's the proper way to do this? This is not a support forum, and the bug is about something else. So better take this to the mailing list. But the solution is to set the "latency" property on rtspsrc (which you can also do via playbin).
(In reply to mark.dion91 from comment #7) > I am not explicitly setting the GstContext on the pipeline. Then this strikes me as odd and unfortunately requires some more debugging to find out where the invalid context comes from.
commit 556c540ecdd9adf516e6d6d78e434ed20fdcb895 Author: Matthew Waters <matthew@centricular.com> Date: Tue Sep 27 00:00:30 2016 +1000 element: use g_strcmp0 in set_context It's NULL-safe while the libc implementation may not be. https://bugzilla.gnome.org/show_bug.cgi?id=771773 commit 3654d844c152db4faced42c15ed40e05b7bd4177 Author: Matthew Waters <matthew@centricular.com> Date: Mon Sep 26 23:59:29 2016 +1000 element: check for invalid gstcontext's being provided to set_context https://bugzilla.gnome.org/show_bug.cgi?id=771773
What should we do about this one then? There's clearly a problem left, it would never be NULL otherwise.
I actually get the same error whether I use these lines or not. pipeline = gst_player_get_pipeline(player->player); gst_pipeline_use_clock(GST_PIPELINE (pipeline), NULL); So the issue is actually not with my additions, since this crash occurs even if I'm using an unmodified version of player.c
mark, do you still get the same issue with current gstreamer (1.14) ?
-- 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/189.