[Bug 682239] Crash on GST_PAD_STREAM_UNLOCK (peer) in gst_pad_push()

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=682239
  GStreamer | gstreamer (core) | 0.10.36

Marcin Lewandowski <www> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|NOTGNOME                    |

--- Comment #8 from Marcin Lewandowski <www at saepia.net> 2012-08-21 11:29:45 UTC ---
Hi, 

I've did some investigation. I am sure that for 95% it is NOT my fault ;)

I've run the same code, many times with refcount tracking.

When it works OK it results in:


2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: pipeline
pad is not null
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: unlinking
from adder
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: pipeline
pad ref count = 3
0:00:25.314535111  4655  0x94233b0 INFO        GST_ELEMENT_PADS
gstpad.c:1750:gst_pad_unlink: unlinking source_test_BIN:src(0x94209c0) and
patchbay_adder:sink1(0x9574198)
0:00:25.314589657  4655  0x94233b0 INFO        GST_ELEMENT_PADS
gstpad.c:1795:gst_pad_unlink: unlinked source_test_BIN:src and
patchbay_adder:sink1
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: releasing
unnecessary adder pad
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: pipeline
pad ref count = 3
0:00:25.314797505  4655  0x94233b0 INFO        GST_ELEMENT_PADS
gstelement.c:847:gst_element_remove_pad:<patchbay_adder> removing pad 'sink1'
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: unref
unnecessary adder pad
2012-08-21 13:21:53.925 [APP  0x94233b0 DEBG] [Source "test"] Detach: pipeline
pad ref count = 2



But sometimes, exactly the same code, in the same environment outputs:


2012-08-21 13:12:39.878 [APP  0x8544950 DEBG] [Source "test"] Detach: pipeline
pad is not null
2012-08-21 13:12:39.878 [APP  0x8544950 DEBG] [Source "test"] Detach: unlinking
from adder
2012-08-21 13:12:39.878 [APP  0x8544950 DEBG] [Source "test"] Detach: pipeline
pad ref count = 4
0:00:28.299488714  4595  0x8544950 INFO        GST_ELEMENT_PADS
gstpad.c:1750:gst_pad_unlink: unlinking source_test_BIN:src(0x85421c0) and
patchbay_adder:sink1(0x86961a0)
0:00:28.299591241  4595  0x8544950 INFO        GST_ELEMENT_PADS
gstpad.c:1795:gst_pad_unlink: unlinked source_test_BIN:src and
patchbay_adder:sink1
2012-08-21 13:12:39.879 [APP  0x8544950 DEBG] [Source "test"] Detach: releasing
unnecessary adder pad
2012-08-21 13:12:39.879 [APP  0x8544950 DEBG] [Source "test"] Detach: pipeline
pad ref count = 4
0:00:28.300200746  4595  0x85449b0 WARN             collectpads
gstcollectpads.c:1421:gst_collect_pads_chain: sink1 got removed from
collectpads
0:00:28.300296847  4595  0x8544950 INFO        GST_ELEMENT_PADS
gstelement.c:847:gst_element_remove_pad:<patchbay_adder> removing pad 'sink1'
2012-08-21 13:12:39.879 [APP  0x8544950 DEBG] [Source "test"] Detach: unref
unnecessary adder pad
2012-08-21 13:12:39.880 [APP  0x8544950 DEBG] [Source "test"] Detach: pipeline
pad ref count = 1
2012-08-21 13:12:39.880 [APP  0x8544950 DEBG] [Source "test"] Detach: setting
pipeline pad to null
2012-08-21 13:12:39.880 [GST  0x8544950 CRIT] gst_object_unref: assertion
`((GObject *) object)->ref_count > 0' failed
2012-08-21 13:12:39.882 [APP  0x8544950 DEBG] [Source "test"] Detach: stop
playback and remove bin from parent - scheduling in idle
2012-08-21 13:12:39.882 [APP  APPTHREAD DEBG] [Source "test"] Detach: Stopping
playback


Obviously, I can add (and I will) some checks to decide whether I should unref
or not based on current ref_count, but don't you think that Gst behaviour in
such case should be more predictable?

Now I am just following the documentation, and in 50% of cases I encounter
ref_count error that is related to GStreamer internals.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.