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 720344 - segfault playing music over http (gst_message_set_buffering_stats)
segfault playing music over http (gst_message_set_buffering_stats)
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.2.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-12-12 19:16 UTC by Dirk-Jan C. Binnema
Modified: 2015-03-25 06:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Dirk-Jan C. Binnema 2013-12-12 19:16:55 UTC 
While playing some music from some http-source (using a playbin element), I hit a segfault. I haven't been able to reproduce it, hopefully this help (it seems we're getting NULL message, which GST_MESSAGE_TYPE tries to dereference.

[Thread 0x7fffc1ffa700 (LWP 26229) exited]

(player:31387): GStreamer-CRITICAL **: gst_message_new_buffering: assertion 'percent >= 0 && percent <= 100' failed

Program received signal SIGSEGV, Segmentation fault.

+ Trace 232914

Thread 140737297782528 (LWP 2300)

  • #0 gst_message_set_buffering_stats
    at gstmessage.c line 1051
  • #1 update_buffering
    at gstqueue2.c line 920
  • #2 gst_queue2_locked_dequeue
    at gstqueue2.c line 2161
  • #3 gst_queue2_push_one
    at gstqueue2.c line 2563
  • #4 gst_queue2_loop
    at gstqueue2.c line 2677
  • #5 gst_task_func
    at gsttask.c line 316
  • #6 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #7 g_thread_proxy
    at gthread.c line 798
  • #8 start_thread
    at pthread_create.c line 309
  • #9 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111 






Comment 1


Sebastian Dröge (slomo)





          2013-12-14 17:59:31 UTC
        



This can only happen if the percentage is lower than 0, higher than 100 is already checked and clipped then to 100.

Lower than 0 can only happen due to overflows when calculating the percentage based on the rate estimation if I didn't miss anything. Hard to say what exactly the problem here is without seeing debug logs or having a way to reproduce.






Comment 2


Dirk-Jan C. Binnema





          2015-03-25 06:21:52 UTC
        



Haven't seen this in a loooong time, so am going to close this.