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 723209 - GStreamer core dump when application is killed if pipeline is not set to null
GStreamer core dump when application is killed if pipeline is not set to null
Status: RESOLVED FIXED
Product: gnome-sound-recorder
Classification: Other
Component: General
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-sound-recorder maintainer(s)
gnome-sound-recorder maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-01-29 02:13 UTC by Meg Ford
Modified: 2014-04-14 03:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Meg Ford 2014-01-29 02:13:12 UTC
the pipeline in the waveform that is created using Gst.parse_launch() produces the following debug info when the application is killed during playback.

    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element capsfilter1, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element fakesink15, but it is in READY instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element level, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element audioconvert1, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element pipeline1, but it is in READY instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element typefind, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element decodebin7, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element source, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
     
    (gnome-sound-recorder:2462): GStreamer-CRITICAL **:
    Trying to dispose element decode, but it is in PAUSED instead of the NULL state.
    You need to explicitly set elements to the NULL state before
    dropping the final reference, to allow them to clean up.
    This problem may also be caused by a refcounting bug in the
    application or some element.
     
    Bus error (core dumped)
Comment 1 Meg Ford 2014-01-29 02:28:18 UTC
IRC conversation:
(05:44:28 PM) m_22: Is it normal to get a core dump if I kill an application while a pipeline is set to paused?
(05:46:33 PM) stormer: nop, but not necessarily gstreamer fault
(05:47:13 PM) stormer: m_22: so you have a signal handler, and if so, what does it do ?
(05:50:50 PM) jaami-win [~jaami@182.189.58.209] entered the room.
(05:57:20 PM) m_22: No, I'm not using the signals module. I'll look at that, thanks.
(06:04:48 PM) m_22: you aren't talking about a signal handler in GStreamer, right stormer? you mean for the overall application.
(06:06:01 PM) __tim: m_22, I would say if it's normal or not depends on a number of things, e.g. if you enabled core dumps, what signal you sent to it, etc. Are you saying you only get a core dump in this specific transition, but not if you kill it in another state?
(06:07:19 PM) m_22: lemme check, __tim. I think it's just in one circumstance.
(06:08:18 PM) m_22: Yes, it's only if I kill the application while a certain pipeline is running
(06:11:11 PM) m_22: http://fpaste.org/72582/
(06:18:13 PM) stormer: m_22: I don't see how, withouth any signal handle of some sort, you would get memory to be released before the process quits
(06:18:53 PM) staylor left the room (quit: Ping timeout: 245 seconds).
(06:18:54 PM) stormer: but one thing is clearly stated in the criticals you have posted, you need to set the elements to NULL state before you remove the final reference
(06:22:48 PM) __tim: might it be the language bindings cleaning up stuff? (without shutting down the pipeline first)
(06:23:29 PM) stormer: is it in python ?
(06:23:33 PM) m_22 left the room (quit: Ping timeout: 248 seconds).
(06:23:34 PM) stormer: or some other language ?
(06:23:45 PM) m_22: it's the only pipeline where I use Gst Launch so maybe that accounts for the difference
(06:24:07 PM) m_22: it's gjs
(06:24:24 PM) stormer: ok, then __tim suggestion is plausible
(06:25:19 PM) stormer: I guess you need to find how to catch for yourself the kill signal in gjs, and handle it (though you can't set NULL state within the signal handler normally, but I would be surprise if this is directly exposed to gjs)
(06:25:50 PM) m_22: right I think you might be able to use the signals module for it
(06:26:10 PM) stormer: there must be some binding specific wrapper of it
(06:26:37 PM) ***stormer wonder why gjs bother cleaning up memory when it's killed ...
(06:27:31 PM) stormer: m_22: but anyway, it's kind of cool to catch that, since maybe you would like to send an eos to close the output file during a record
(06:28:36 PM) m_22: idk if it's a gjs issue, as I said it's only when I launch the pipeline using Gst.parse_launch not in general
(06:29:28 PM) m_22: I'm not sure if I'm using bindings there
(06:30:02 PM) m_22: In which case maybe I need to free the memory manually? I have to do that with Cairo for example
(06:30:42 PM) stormer: it's application fault, you need to set pipeline to NULL somehow before memory is freed
(06:31:20 PM) stormer: whatever the binding is, you need to do that manually as the binding don't know about GST
(06:31:43 PM) stormer: if you don't have crash in other cases, it's probably more of a luck
(06:32:07 PM) m_22: dumb luck
(06:32:20 PM) m_22: ok thanks I'll look at signals then :)
(06:33:16 PM) stormer: m_22: the difference with parse launch is that you're pipeline may now be dynamically linked, so a bit more asynchronicity, thus a bit more risk when doing things wrong
Comment 2 Meg Ford 2014-04-14 03:24:48 UTC
Fixed according to Nicolas Dufresne's recommendations: https://git.gnome.org/browse/gnome-sound-recorder/commit/?id=bcfa16cd34367aa5919ce273345d6fd49ef1e8e3