GNOME Bugzilla – Bug 502593
State change failure (with gstvideogui.py)
Last modified: 2009-09-10 08:25:50 UTC
Steps to reproduce: Run the attached python program. Click "play" once to start video. Then click "record" to start a recording. Wait for a few seconds, and then click "record" again to stop recording. You should now have a recorded file under /tmp. Click "record" once more (as if you wanted to start a new recording), the program now hangs. Stack trace: Other information:
Created attachment 100619 [details] Python program showing the bug
I can reproduce this with git. It seems to hang in _get_state() around line 150: if (self.rcc == 3): print "The next line is where the program hangs. Goodbye." ret = self.pipeline.set_state(gst.STATE_PLAYING) state = self.pipeline.get_state() self.recording = True and the debug log shows an endless loop of: gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b74820] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b74820] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b74820] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74758] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74758] dropped gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b746d8] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b746d8] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b746d8] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74658] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74658] dropped gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b745d8] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b745d8] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b745d8] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74558] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74558] dropped gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b744d8] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b744d8] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b744d8] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74458] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74458] dropped gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b74390] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b74390] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b74390] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74310] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74310] dropped gstbus.c:308:gst_bus_post:<bus3> [msg 0x8b74290] posting on bus, type async-done, (NULL) from source <mypipeline> gstbus.c:338:gst_bus_post:<bus3> [msg 0x8b74290] pushing on async queue gstbus.c:343:gst_bus_post:<bus3> [msg 0x8b74290] pushed on async queue gstbus.c:308:gst_bus_post:<bus2> [msg 0x8b74210] posting on bus, type async-done, (NULL) from source <bin0> gstbus.c:334:gst_bus_post:<bus2> [msg 0x8b74210] dropped The code of this application is so, umm, nonstandard, that I don't even know where to begin. It has _get_state() sprinkled all over the place as if there was a Nobel prize for it, hardly any checking of return values anywhere (set_state, etc. etc.), no error handling (maybe I missed it?), and you set your own bus on random elements, like here: self.filesink.set_bus(gst.Bus()) self.filesink.get_bus().add_watch(self.__myFilesinkWatchCb) Please supply an updated version of your test program that doesn't do crazy stuff, or close this bug as OBSOLETE, thanks! :)
If you can reproduce this with current git, I don't consider it obsolete and won't close it as such. To rewrite to test program to not do crazy stuff is essentially saying; "go find the error yourself". Well, I would if I could. And this bug report would never have been written. But I can't, and here we are.
I told you a bunch of errors, you could start by fixing those. It's well possible that there is a bug in GStreamer, but I'm not willing to look at this problem further before those obvious code problems are taken care of. Maybe someone else will, who knows, but I suspect not. If you need advice on how to do stuff, please ask on the mailing list. I'm not asking you to find the bug yourself, just to provide test code that's not obviously wrong and has basic error handling.
So that would be... 1. Remove all _get_state() that's not explicitly needed 2. Check return values and implement proper error handling 3. Don't set your own bus on random elements Sure, when I find the time.
Let's close this bug for now then, feel free to reopen if you still get the same issue with correct code.