GNOME Bugzilla – Bug 701319
input-selector: pads don't notify when "active" changes
Last modified: 2013-06-06 15:18:02 UTC
Created attachment 245685 [details] Hook up callbacks for notify::tags and notify::active and see that notify::active doesn't do anything input-selector's pads don't notify when the "active" property changes. I had assumed it was as simple as changing the two cases of: g_object_notify (G_OBJECT (sel), "active-pad"); To: g_object_notify (G_OBJECT (sel), "active-pad"); if (prev_active_sinkpad) g_object_notify (G_OBJECT (prev_active_sinkpad), "active"); if (active_sinkpad) g_object_notify (G_OBJECT (active_sinkpad), "active"); But that causes memory corruption..
I guess in theory it would be possible for the prev_active_sinkpad to disappear before that function (because we own no additional reference to it). Otherwise I don't see why this would crash and cause memory corruption. Can you get the relevant information from valgrind with --track-origins=yes?
Created attachment 245752 [details] [review] (Don't commit this) Send "active" signal whenever we send "active-pad" signal. I attached my patch, which doesn't work at the moment. Here's the output: Switching audio track to 1 Switching video track to 1 Switching audio track to 1 ==14141== Thread 5: ==14141== Invalid read of size 4 ==14141== at 0x41ED64: PyObject_Call (in /usr/bin/python3.2mu) ==14141== by 0x457865: PyEval_CallObjectWithKeywords (in /usr/bin/python3.2mu) ==14141== by 0x9A12E47: ??? (in /usr/lib/python3/dist-packages/gi/_gobject/_gobject.cpython-32mu.so) ==14141== by 0x80D1CA1: g_closure_invoke (gclosure.c:777) ==14141== by 0x80E2D70: signal_emit_unlocked_R (gsignal.c:3547) ==14141== by 0x80EB098: g_signal_emit_valist (gsignal.c:3296) ==14141== by 0x80EB241: g_signal_emit (gsignal.c:3352) ==14141== by 0xA044106: pad_added_cb (gstplaybin2.c:3148) ==14141== by 0x80D5353: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1312) ==14141== by 0x80D1EC9: _g_closure_invoke_va (gclosure.c:840) ==14141== by 0x80EA740: g_signal_emit_valist (gsignal.c:3207) ==14141== by 0x80EB241: g_signal_emit (gsignal.c:3352) ==14141== Address 0x18 is not stack'd, malloc'd or (recently) free'd ==14141== ==14141== ==14141== Process terminating with default action of signal 11 (SIGSEGV) ==14141== Access not within mapped region at address 0x18 ==14141== at 0x41ED64: PyObject_Call (in /usr/bin/python3.2mu) ==14141== by 0x457865: PyEval_CallObjectWithKeywords (in /usr/bin/python3.2mu) ==14141== by 0x9A12E47: ??? (in /usr/lib/python3/dist-packages/gi/_gobject/_gobject.cpython-32mu.so) ==14141== by 0x80D1CA1: g_closure_invoke (gclosure.c:777) ==14141== by 0x80E2D70: signal_emit_unlocked_R (gsignal.c:3547) ==14141== by 0x80EB098: g_signal_emit_valist (gsignal.c:3296) ==14141== by 0x80EB241: g_signal_emit (gsignal.c:3352) ==14141== by 0xA044106: pad_added_cb (gstplaybin2.c:3148) ==14141== by 0x80D5353: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1312) ==14141== by 0x80D1EC9: _g_closure_invoke_va (gclosure.c:840) ==14141== by 0x80EA740: g_signal_emit_valist (gsignal.c:3207) ==14141== by 0x80EB241: g_signal_emit (gsignal.c:3352) ==14141== If you believe this happened as a result of a stack ==14141== overflow in your program's main thread (unlikely but ==14141== possible), you can try to increase the size of the ==14141== main thread stack using the --main-stacksize= flag. ==14141== The main thread stack size used in this run was 8388608
Fixed them, just some missing NULL checks and a refcount problem commit f0a3d8bb096c301134af45eeb04db9fa3d118d4d Author: Brendan Long <b.long@cablelabs.com> Date: Fri May 31 09:39:55 2013 -0600 input-selector: send notify::active signal for input-selector pads. https://bugzilla.gnome.org/show_bug.cgi?id=701319