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 767666 - splitmuxsink: infinite change_state loop
splitmuxsink: infinite change_state loop
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal normal
: 1.8.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-14 21:06 UTC by Xavier Claessens
Modified: 2018-11-03 15:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Xavier Claessens 2016-06-14 21:06:03 UTC
I override GstElementClass::change_state() in the parent GstBin containing splitmuxsink. Since 1.8.2 (was not in 1.8.1) I see that it's being called in loop with transition PAUSED to PLAYING.

Reverting a97face and f2872ee fix the problem.
Comment 1 Tim-Philipp Müller 2016-06-14 21:23:01 UTC
What does your new change_state function look like?

Does it also happen if you don't override it?
Comment 2 Xavier Claessens 2016-06-15 01:29:53 UTC
It is a trivial print debug and chain up. I use GST_STATE_TRANSITION_CURRENT/NEXT to know it's a PAUSED->PLAYING transition.
Comment 3 Tim-Philipp Müller 2016-06-15 08:41:54 UTC
So it also happens if you don't override it?

Do you have a way to reproduce the problem?
Comment 4 Xavier Claessens 2016-06-15 13:04:28 UTC
(In reply to Tim-Philipp Müller from comment #3)
> So it also happens if you don't override it?

Yes, but you won't notice it actually happens. As far as I can tell, everything still works perfectly. If I hadn't that debug print I wouldn't have noticed that regression.

> Do you have a way to reproduce the problem?

I haven't tried to write a test case yet, will try to make one.


Worth noting that in my case splitmuxsink is wrapped into a bin that has async-handling = TRUE.
Comment 5 Jan Schmidt 2016-06-17 15:05:46 UTC
I don't understand your bug description. How can you have an infinite looping state change function and not see any outward signs. You'd think it'd crash or use 100% CPU or something.
Comment 6 Tim-Philipp Müller 2016-06-17 15:07:15 UTC
Setting NEEDINFO. I think we need a way to reproduce it or at least a debug log.
Comment 7 Tim-Philipp Müller 2016-06-17 15:11:05 UTC
Also marking as blocker since it sounds like it's a regression from 1.8.1 to 1.8.2.
Comment 8 Xavier Claessens 2016-06-17 16:25:01 UTC
(In reply to Jan Schmidt from comment #5)
> I don't understand your bug description. How can you have an infinite
> looping state change function and not see any outward signs. You'd think
> it'd crash or use 100% CPU or something.

State transition is made from another thread, it is gst_bin_continue_func() that runs in loop, if I understand correctly. So that's not preventing the rest of the pipeline to work.

This clearly needs a test case, I'll try to find time to write one.
Comment 9 Jan Schmidt 2016-08-07 17:40:05 UTC
This seems to be a fundamental problem in core with bins that have async-handling=TRUE because they don't send async-start, but return ASYNC from the state change function. The pipeline just tries to continue state constantly because it has no async-start message stored from the child.

For now, I've reverted the commit which switched from using some internal logic to using the bin's async-handling.

commit 5a71334fb0be6f1bd4c15815c7dad3567306d47b
Author: Jan Schmidt <jan@centricular.com>
Date:   Mon Aug 8 02:53:48 2016 +1000

    Revert "splitmuxsink: Use GstBin async-handling instead of our own."
    
    This reverts commit fa008f271a52f82dededc28bd81b020ca7939b47.
    
    async-handling in GstBin causes the pipeline to spin at 100%
    CPU as the top-level pipeline tries to change that state
    to PLAYING constantly. This is a workaround for a core
    problem, essentially, but an improvement in this case for now.
Comment 10 Tim-Philipp Müller 2016-08-08 13:19:32 UTC
No longer a blocker.
Comment 11 Xavier Claessens 2016-08-08 14:00:22 UTC
(In reply to Jan Schmidt from comment #9)
> This seems to be a fundamental problem in core with bins that have
> async-handling=TRUE because they don't send async-start, but return ASYNC
> from the state change function. The pipeline just tries to continue state
> constantly because it has no async-start message stored from the child.

So that should happen with other elements than splitmuxsink? That sounds more blocker than ever, no?
Comment 12 Jan Schmidt 2016-08-08 14:02:34 UTC
No, a blocker is something we should hold the release for. Fundamental problems that have existed for who-knows-how-long without causing widespread trouble generally aren't, even if they *do* need fixing.
Comment 13 Xavier Claessens 2016-08-08 14:08:06 UTC
ok, didn't know that has always been like that. Surely there is a bug opened for it already then? Should we close this one as dup ?
Comment 14 GStreamer system administrator 2018-11-03 15:09:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/280.