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 674574 - playbin about-to-finish signal Segfault with pygi
playbin about-to-finish signal Segfault with pygi
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-python
0.10.x
Other Linux
: High critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-04-22 17:08 UTC by Jonas H.
Modified: 2012-12-17 11:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The sound used to reproduce the bug (8.78 KB, video/ogg)
2012-04-22 17:08 UTC, Jonas H.
Details

Description Jonas H. 2012-04-22 17:08:32 UTC
Created attachment 212550 [details]
The sound used to reproduce the bug

Running this code http://paste.pocoo.org/show/585630/ results in this crash http://paste.pocoo.org/show/585628/ after the sound has been played.

python-gst 0.10.22
Comment 1 André Klapper 2012-04-22 19:51:53 UTC
Thanks!Thanks for taking the time to report this.
Unfortunately, that stacktrace misses debug symbols for glib2 and gstreamer. Please install them first and paste an updated stacktrace as a comment in this bug report. See http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!
Comment 2 Jonas H. 2012-04-22 20:41:55 UTC
I can do that but maybe you can reproduce the crash yourself so I don't have to go through all the compilation hassle?
Comment 3 André Klapper 2012-04-23 07:49:23 UTC
Here you go on Fedora16:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb70ffb40 (LWP 3301)]
0x44d05189 in PyObject_Call (func=<function at remote 0xb7c4dfb4>, arg=(<__main__.GstPlayBin2 at remote 0xb7c61d24>,), kw=0x0)
    at /usr/src/debug/Python-2.7.2/Objects/abstract.c:2527
2527	        if (Py_EnterRecursiveCall(" while calling a Python object"))
(gdb) thread apply all bt

Thread 3 (Thread 0xb70ffb40 (LWP 3301))

  • #0 PyObject_Call
  • #1 PyEval_CallObjectWithKeywords
  • #2 PyObject_CallObject
  • #3 pyg_closure_marshal
    at pygtype.c line 1217
  • #4 g_closure_invoke
    at gclosure.c line 774
  • #5 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #6 g_signal_emit_valist
    at gsignal.c line 3003
  • #7 g_signal_emit
    at gsignal.c line 3060
  • #8 drained_cb
    at gstplaybin2.c line 2895
  • #9 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 85
  • #10 g_closure_invoke
    at gclosure.c line 774
  • #11 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #12 g_signal_emit_valist
    at gsignal.c line 3003
  • #13 g_signal_emit
    at gsignal.c line 3060
  • #14 proxy_drained_signal
    at gsturidecodebin.c line 1518
  • #15 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 85
  • #16 g_closure_invoke
    at gclosure.c line 774
  • #17 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #18 g_signal_emit_valist
    at gsignal.c line 3003
  • #19 g_signal_emit
    at gsignal.c line 3060
  • #20 gst_decode_chain_handle_eos
    at gstdecodebin2.c line 2927
  • #21 gst_decode_pad_handle_eos
    at gstdecodebin2.c line 2868
  • #22 source_pad_event_probe
    at gstdecodebin2.c line 3442
  • #23 source_pad_event_probe
    at gstdecodebin2.c line 3432
  • #24 gst_marshal_BOOLEAN__POINTER
    at gstmarshal.c line 586
  • #25 g_closure_invoke
    at gclosure.c line 774
  • #26 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #27 g_signal_emitv
    at gsignal.c line 2907
  • #28 gst_pad_emit_have_data_signal
    at gstpad.c line 4143
  • #29 gst_pad_push_event
    at gstpad.c line 5236
  • #30 gst_proxy_pad_do_event
    at gstghostpad.c line 114
  • #31 gst_pad_send_event
    at gstpad.c line 5398
  • #32 gst_pad_push_event
    at gstpad.c line 5250
  • #33 vorbis_dec_sink_event
    at gstvorbisdec.c line 544
  • #34 gst_pad_send_event
    at gstpad.c line 5398
  • #35 gst_pad_push_event
    at gstpad.c line 5250
  • #36 gst_single_queue_push_one
    at gstmultiqueue.c line 1004
  • #37 gst_multi_queue_loop
    at gstmultiqueue.c line 1179
  • #38 gst_task_func
    at gsttask.c line 318
  • #39 default_func
    at gsttaskpool.c line 70
  • #40 g_thread_pool_thread_proxy
    at gthreadpool.c line 319
  • #41 g_thread_create_proxy
    at gthread.c line 1962
  • #42 start_thread
    at pthread_create.c line 309
  • #43 clone
    at ../sysdeps/unix/sysv/linux/i386/clone.S line 133

Comment 4 Thiago Sousa Santos 2012-04-30 14:49:41 UTC
The paste site you used has shut down, could you attach the files here or use a different service?
Comment 5 Jonas H. 2012-04-30 16:18:41 UTC
André has already posted a much better traceback for the same bug.
Comment 6 Thiago Sousa Santos 2012-04-30 16:45:18 UTC
I was looking for the code that you also pasted there.
Comment 7 Jonas H. 2012-04-30 16:57:20 UTC
Right, here you go


from gi.repository import Gst

Gst.init(None)

def on_about_to_finish(playbin):
    pass

playbin = Gst.ElementFactory.make('playbin2', 'playbin')
playbin.set_property('uri', 'file:///jonas/stuff/noise.ogg')
playbin.set_state(Gst.State.PLAYING)
playbin.connect('about-to-finish', on_about_to_finish)
# ausprobieren mit audio-sinks und dann bugreport filen

import time
while 1:
    time.sleep(.1)
Comment 8 Tim-Philipp Müller 2012-09-23 18:33:59 UTC
> from gi.repository import Gst

Not a gst-python bug then. Just to be sure, py-gi will never work right with GStreamer 0.10.x.

The crash is also reproducable with GStreamer 0.11/1.0 though. Don't see anything wrong with our signal registration, so I would suspect a pygobject bug.
Comment 9 Sebastian Dröge (slomo) 2012-12-17 11:43:00 UTC
Closing this bug now, gst-python is only an extension module to pygi now and this bug doesn't make much sense anymore in this context.