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 771773 - Android: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Android: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.9.2
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-21 15:23 UTC by mark.dion91
Modified: 2018-11-03 12:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Logcat logs with GStreamer logging at highest level, including backtrace (44.27 KB, text/plain)
2016-09-21 15:23 UTC, mark.dion91
  Details
backtrace after ndk-stack (with *.c files and line numbers) (19.12 KB, text/plain)
2016-09-26 13:41 UTC, mark.dion91
  Details
element: check for invalid gstcontext's being provided (1.26 KB, patch)
2016-09-26 14:06 UTC, Matthew Waters (ystreet00)
committed Details | Review
element: use g_strcmp0 in set_context (1009 bytes, patch)
2016-09-26 14:06 UTC, Matthew Waters (ystreet00)
committed Details | Review

Description mark.dion91 2016-09-21 15:23:02 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.
Comment 1 Matthew Waters (ystreet00) 2016-09-22 00:11:19 UTC
Can you run addr2line on the values below and including the gst_gl_ensure_element_data stack frame please?
Comment 2 mark.dion91 2016-09-26 13:41:45 UTC
Created attachment 336263 [details]
backtrace after ndk-stack (with *.c files and line numbers)
Comment 3 Matthew Waters (ystreet00) 2016-09-26 13:49:46 UTC
So, one of the arguments to strcmp is NULL.
Comment 4 Matthew Waters (ystreet00) 2016-09-26 14:06:14 UTC
Created attachment 336265 [details] [review]
element: check for invalid gstcontext's being provided
Comment 5 Matthew Waters (ystreet00) 2016-09-26 14:06:41 UTC
Created attachment 336266 [details] [review]
element: use g_strcmp0 in set_context
Comment 6 Matthew Waters (ystreet00) 2016-09-26 14:11:29 UTC
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?
Comment 7 mark.dion91 2016-09-26 14:20:10 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2016-09-26 14:22:43 UTC
(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.
Comment 9 Sebastian Dröge (slomo) 2016-09-26 14:23:00 UTC
Oops, ignore the part at the end. Clicked on the wrong button
Comment 10 mark.dion91 2016-09-26 14:46:15 UTC
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?
Comment 11 Sebastian Dröge (slomo) 2016-09-26 14:54:46 UTC
(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).
Comment 12 Matthew Waters (ystreet00) 2016-09-27 06:46:05 UTC
(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.
Comment 13 Matthew Waters (ystreet00) 2016-10-19 11:25:54 UTC
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
Comment 14 Sebastian Dröge (slomo) 2016-10-19 11:46:01 UTC
What should we do about this one then? There's clearly a problem left, it would never be NULL otherwise.
Comment 15 mark.dion91 2016-10-25 14:51:00 UTC
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
Comment 16 Edward Hervey 2018-05-04 09:27:41 UTC
mark, do you still get the same issue with current gstreamer (1.14) ?
Comment 17 GStreamer system administrator 2018-11-03 12:36:22 UTC
-- 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.