Bug 291821 - memory leak w/ gstreamer error/failure
Summary: memory leak w/ gstreamer error/failure
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: pidgin
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Warren Togami
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-15 00:29 UTC by Tom London
Modified: 2008-01-04 03:19 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-01-04 03:19:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tom London 2007-09-15 00:29:45 UTC
Description of problem:
I noticed that my copy of pidgin had a virt. footprint of over 600M.

I restarted in a terminal window with "pidgin -d", and in a second window ran top.

I noticed that pidgin grew by about 32MB when the following messages were produced:

(17:23:56) gstreamer: Internal GStreamer error: state change failed.  Please
file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.

(pidgin:729): GStreamer-CRITICAL **: 
Trying to dispose element fakesink, but it is not in the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.

(17:23:56) yahoo: 40 bytes to read, rxlen is 60
(17:23:56) yahoo: Yahoo Service: 0xc6 Status: 1
(17:23:56) blist: Updating buddy status for samir_s_patel (Yahoo)
(17:23:57) blist: Updating buddy status for samir17 (AIM)
(17:23:57) oscar: Connecting to FLAP server 64.12.30.84:5190 of type 0x0010
(17:23:57) dns: DNS query for '64.12.30.84' queued
(17:23:57) dns: Created new DNS child 1307, there are now 1 children.
(17:23:57) dns: Successfully sent DNS request to child 1307
(17:23:57) dns: Got response for '64.12.30.84'
(17:23:57) dnsquery: IP resolved for 64.12.30.84
(17:23:57) proxy: Attempting connection to 64.12.30.84
(17:23:57) proxy: Connecting to 64.12.30.84:5190 with no proxy
(17:23:57) proxy: Connection in progress
(17:23:57) proxy: Connected to 64.12.30.84:5190.
(17:23:57) oscar: connected to FLAP server of type 0x0010
(17:23:58) oscar: FLAP connection of type 0x0010 is now fully connected
(17:23:58) oscar: no more icons to request
(17:24:05) oscar: Scheduling destruction of FLAP connection of type 0x0007
(17:24:05) oscar: Destroying oscar connection of type 0x0007.  Disconnect reason
is 2
(17:24:05) oscar: Disconnected.  Code is 0x0000 and msg is 

Not sure if this is pidgin or gstreamer......

Version-Release number of selected component (if applicable):
pidgin-2.1.1-1.fc8
gstreamer-0.10.14-3.fc8


How reproducible:
every time

Steps to Reproduce:
1. Start pidgin 
2. Observe allocated memory via top
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Tom London 2007-09-15 00:40:00 UTC
As indicated in gstreamer message, I filed this upstream here:
http://bugzilla.gnome.org/show_bug.cgi?id=477086

Comment 2 Tom London 2007-09-18 13:23:12 UTC
Got the following from upstream gstreamer bugzilla:

------- Comment #1 from Tim-Philipp Müller  2007-09-18 08:55 UTC -------
The first is fixed in -good CVS (sort of, at least the nonsensical error
message).

The criticial warning (and memory leak) are probably pidgin bugs (not cleaning
up properly in the error code path), so I'd suggest you take it up with them
first.

If it's really a GStreamer leak, a small stand-alone test case or a valgrind
leakcheck log with full debugging symbols against GStreamer CVS would be very
helpful.



Comment 3 Tom London 2007-09-18 14:05:01 UTC
Filed this upstream on pidgin here: https://developer.pidgin.im/ticket/3182

Comment 4 Tom London 2007-09-19 13:26:17 UTC
Thanks for updating to 2.2.0-2!

Here is response to upstream bz:
Change History
09/18/2007 10:40:04 PM changed by QuLogic

Since you're still using 2.1.1, dupe of #2663.
09/18/2007 11:03:53 PM changed by datallah

    * status changed from new to closed.
    * resolution set to duplicate.

I'll monitor today, and close if all goes well.

thanks,
   tom


Comment 5 Tom London 2007-09-19 13:45:26 UTC
Sorry, but this is not fixed.

I can make the VIRT size go up by sending myself messages (by about 20-30MB).

Now complains about 'play' instead of 'fakesink'.

Here are the 'new' error messages:

(06:42:09) GLib-GObject: cannot register existing type `GstMixerTrack'
(06:42:09) GLib-GObject: g_object_new: assertion `G_TYPE_IS_OBJECT
(object_type)' failed
(06:42:09) GLib-GObject: cannot register existing type `GstMixerTrack'
(06:42:09) gstreamer: Internal GStreamer error: state change failed.  Please
file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.


(pidgin:6684): GStreamer-CRITICAL **:
Trying to dispose element play, but it is not in the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.

(06:42:09) gstreamer: Internal GStreamer error: state change failed.  Please
file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.

(pidgin:6684): GStreamer-CRITICAL **: gst_element_set_state: assertion
`GST_IS_ELEMENT (element)' failed
(06:42:09) GLib-GObject: invalid unclassed pointer in cast to `GstObject'

(pidgin:6684): GStreamer-CRITICAL **: gst_object_unref: assertion `((GObject *)
object)->ref_count > 0' failed
(06:42:09) GLib-GObject: invalid unclassed pointer in cast to `GstPlayBaseBin'
(06:42:09) oscar: Incoming rendezvous message of type 1, user Tom London, status 0
(06:42:09) oscar: Sent message to Tom London.
(06:42:14) util: Writing file blist.xml to directory /home/tbl/.purple
(06:42:14) util: Writing file /home/tbl/.purple/blist.xml
(06:42:15) msn: C: NS 000: PNG
(06:42:15) msn: S: NS 000: QNG 42


Comment 6 Tom London 2007-11-08 15:32:43 UTC
I can no longer reproduce this with pidgin-2.2.2-1.fc8 and pulseaudio enabled.

What I do see, however, is that the VIRT size increases by about 32MB for each
'sound' played.  This increase lasts about 10-20 seconds or so; VIRT size
reverts to prior value.

Close?

Comment 7 Stu Tomlinson 2008-01-04 03:19:46 UTC
Closing, because I don't think transient peaks in pidgin memory usage while
playing sounds are anything directly related to pidgin.


Note You need to log in before you can comment on or make changes to this bug.