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 740191 - dvbbasesink: segfaults on 32-bit (rpi)
dvbbasesink: segfaults on 32-bit (rpi)
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.3
Other Linux
: Normal normal
: 1.4.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-11-15 19:44 UTC by Ayke van Laethem
Modified: 2015-09-13 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ayke van Laethem 2014-11-15 19:44:38 UTC
I get this stack trace when running gmediarender[1] on a Raspberry Pi (ARM), but not when running it on a x86 (64bit) platform. I don't know whether the processor is the issue, it could also just be the different system. Both systems run Debian jessie (the Raspberry Pi runs the specialized ARM port Raspbian[2]).

As removing gst-plugins-bad works around the problem, I believe one of the -bad plugins somehow causes the problem. Looking at the stack trace, it appears to be the dvb (?) plugin.

I reported the issue in Raspbian as well [3], but realized it probably doesn't have anything to do with gmediarender or the Raspbian distro.

Here's the full stack trace:

Program received signal SIGSEGV, Segmentation fault.
strchr () at ../ports/sysdeps/arm/armv6/strchr.S:28
28      ../ports/sysdeps/arm/armv6/strchr.S: No such file or directory.
(gdb) bt
  • #0 strchr
    at ../ports/sysdeps/arm/armv6/strchr.S line 28
  • #1 g_param_spec_pool_lookup
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gparam.c line 1070
  • #2 g_object_set_valist
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gobject.c line 2121
  • #3 g_object_set
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gobject.c line 2269
  • #4 dvb_base_bin_init
    at dvbbasebin.c line 419
  • #5 g_type_create_instance
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gtype.c line 1865
  • #6 g_object_new_internal
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gobject.c line 1774
  • #7 g_object_newv
    at /build/glib2.0-87CS9e/glib2.0-2.42.0/./gobject/gobject.c line 1922
  • #8 gst_element_factory_create
    at gstelementfactory.c line 376
  • #9 scan_mime_list
    at output_gstreamer.c line 133
  • #10 output_gstreamer_init
    at output_gstreamer.c line 494
  • #11 main
    at main.c line 249

[1] https://github.com/hzeller/gmrender-resurrect
[2] http://raspbian.org/
[3] https://bugs.launchpad.net/raspbian/+bug/1392850
Comment 1 Tim-Philipp Müller 2014-11-15 22:05:16 UTC
I think this should fix it:

 commit 3e1d7630187dd96b137553aec2c6edb60c213682
 Author: Tim-Philipp Müller <tim@centricular.com>
 Date:   Sat Nov 15 21:59:48 2014 +0000

    dvbbasebin: fix possible crash by passing 64 bits for 64-bit queue property
    
    https://bugzilla.gnome.org/show_bug.cgi?id=740191


Would be great if you could try it and re-open if not, thanks!
Comment 2 Ayke van Laethem 2014-11-16 20:15:58 UTC
Yes, that fixed it. Thank you for the quick reply!

I tested this by applying the patch (manually) to the Debian source package 1.4.3-2 and building it. That fixed the issue. Then I removed the patch, to be sure, and indeed it segfaulted again.

Building took 5½ hour (twice!) on this little 700MHz ARM board, so that's why it took so long to test.
Comment 3 Tim-Philipp Müller 2014-11-16 20:33:49 UTC
Perfect, thanks for going through the trouble of verifying and confirming that's what it was!
Comment 4 Mostafa Farzane 2015-09-13 12:34:36 UTC
(In reply to Ayke van Laethem from comment #2)
> Yes, that fixed it. Thank you for the quick reply!
> 
> I tested this by applying the patch (manually) to the Debian source package
> 1.4.3-2 and building it. That fixed the issue. Then I removed the patch, to
> be sure, and indeed it segfaulted again.
> 
> Building took 5½ hour (twice!) on this little 700MHz ARM board, so that's
> why it took so long to test.

I know it have been a long time, but I have no choice. How can you did that? I have the same problem with Raspberry Pi.