[gstreamer-bugs] [Bug 514717] memleak in Pad.set_blocked_async()

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=514717

  GStreamer | gst-python | Ver: HEAD CVS

Mark Nauwelaerts changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manauw at skynet.be




------- Comment #3 from Mark Nauwelaerts  2008-05-30 17:37 UTC -------
I am not sure if this introduced other problems, but I now (0.10.11) get
segfault whose backtrace is very close to what has been changed here (see
below; gdb may be a bit off given the O2 optimized code).

I am also not clear on why a Py_DECREF is needed here on py_user_data.
AFAIK, a pad's block callback can be called several times, so
pad_block_callback_marshal can be called more than once with the same
user_data.  In each case, py_user_data refcount is decreased by Py_DECREF, but
I don't know where the refcount of py_user_data is correspondingly increased
with each call [PyTuple_GetItem returns a borrowed reference, so it can't be
there].
If there is indeed no increase of refcount, this decreasing eventually leads to
a premature release of py_user_data.

On the other hand, indeed, if Py_DECREF is not used here, the callback function
does not get released if one does not explicitly call Pad.set_blocked_async()
with an empty handler.  But that seems to be due to the core not employing some
sort of destroy_notify to inform when it is removing refs to the callback.

In any case, presence of Py_DECREF(py_user_data) seems to have a pretty good
correspondence with the occurrence of segfaults (with only minute
non-determinism).

(gdb) frame
#0  pad_block_callback_marshal (pad=0x8522620, blocked=1, user_data=0x847730c)
    at gstpad.override:1345
1345        Py_DECREF(args);
(gdb) bt
#0  pad_block_callback_marshal (pad=0x8522620, blocked=1, user_data=0x847730c)
    at gstpad.override:1345
#1  0xb791196c in handle_pad_block (pad=0x8522620) at gstpad.c:3373
#2  0xb7913b40 in gst_pad_push_event (pad=0x8522620, event=0x814c050) at
gstpad.c:4109
#3  0xb790857a in gst_proxy_pad_do_event (pad=0x8a9acb0, event=0x814c050) at
gstghostpad.c:142
#4  0xb7913146 in gst_pad_send_event (pad=0x8a9acb0, event=0x814c050) at
gstpad.c:4276
#5  0xb7913866 in gst_pad_push_event (pad=0x8a87c90, event=0x814c050) at
gstpad.c:4132
#6  0xb5d3395b in gst_mpeg2dec_sink_event (pad=0x8a87bd0, event=0x814c050) at
gstmpeg2dec.c:1251
#7  0xb7913146 in gst_pad_send_event (pad=0x8a87bd0, event=0x814c050) at
gstpad.c:4276
#8  0xb7913866 in gst_pad_push_event (pad=0x8a87b10, event=0x814c050) at
gstpad.c:4132
#9  0xb75e4321 in gst_multi_queue_loop (pad=0x8a87b10) at gstmultiqueue.c:739
#10 0xb79324d0 in gst_task_func (task=0x8a54320, tclass=0x8a45648) at
gsttask.c:192
#11 0xb7af777b in ?? () from /usr/lib/libglib-2.0.so.0
#12 0x08a54320 in ?? ()
#13 0x08a45648 in ?? ()
#14 0xb7e24431 in pthread_mutex_lock () from /lib/libpthread.so.0
#15 0xb7af5aef in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x08a456d8 in ?? ()
#17 0x08aa8880 in ?? ()
#18 0x00000000 in ?? ()


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=514717.