On Mon, 2009-10-12 at 14:22 +, Bruce Miller wrote:
> Here's the new massif.out
>
> ** Attachment added: "massif.out.14298"
>http://launchpadlibrarian.net/33495789/massif.out.14298
>
I do not believe that this shows a memory leak, merely a usual increase
of heap size due to excessive repe
On Mon, 2009-10-12 at 14:22 +, Bruce Miller wrote:
> Here's the new massif.out
>
> ** Attachment added: "massif.out.14298"
>http://launchpadlibrarian.net/33495789/massif.out.14298
>
OOI how long did you leave this running for? You might need to let it
accumulate more data so that the le
On Mon, 2009-10-12 at 13:18 +, Bruce Miller wrote:
> br...@xenophon:~$ valgrind --tool=massif /bin/dbus-daemon --system
> ==1225== Massif, a heap profiler
> ==1225== Copyright (C) 2003-2009, and GNU GPL'd, by Nicholas Nethercote
> ==1225== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h
On Mon, 2009-10-12 at 04:13 +, Bruce Miller wrote:
> What has not yet declined is the number of zombie bash processes being
> reported by top. These also appear to be related to amarok Are they also
> connected to this dbus-daemon issue?
>
Not sure, but they're definitely amarok's fault.
For
On Mon, 2009-08-17 at 18:00 +, Steve Langasek wrote:
> As far as I'm able to tell, setting --disable-userdb-cache has *no*
> effect on the code in the hardy version of dbus; it sets a define in
> config.h which is then never used. Martin, can you confirm this, or
> else let me know what I've
On Thu, 2009-08-06 at 22:45 +, near wrote:
> As i run an archlinux, it's only a comment to help you find out. i'll
> post this to the dbus bugtracker
>
Again, please run massif over this to track where the memory is going.
It may simply be unreturned heap memory.
Scott
--
Scott James Remnan
On Wed, 2009-07-29 at 09:13 +, Martin Pitt wrote:
> The patch makes sense (I subscribed main sponsors), but it worries me
> that it is still perceived in Karmic (which doesn't disable the userdb
> cache). Is it confirmed that it is the very same problem?
>
I've not seen any evidence of a true
On Wed, 2009-07-22 at 05:46 +, James Andrewartha wrote:
> So are you going to fix the memory leak in hardy, or should I open a new
> bug asking for an SRU?
>
If you'd like an SRU, the procedure for doing so is here:
http://wiki.ubuntu.com/StableReleaseUpdates
(note it doesn't require that yo
On Fri, 2009-07-17 at 02:54 +, Hei Ku wrote:
> I tried to kill dbus-daemon, but KWin died on me and it killed my whole
> session. How can I do it gracefully?
>
You can't, I'm afraid.
Scott
--
Scott James Remnant
sc...@canonical.com
--
dbus-daemon memory leak
https://bugs.launchpad.net/bug
On Thu, 2009-07-16 at 15:07 +, James Andrewartha wrote:
> OK, I've done this and there's a massif.out, but it's not being added to
> even though dbus' memory usage is increasing:
>
You need to terminate the dbus process, and then attach the massif.out
file ;-)
status incomplete
Scott
--
S
On Thu, 2009-07-16 at 06:43 +, James Andrewartha wrote:
> r...@quoll:~ # date;ps avx|grep dbus
> Thu Jul 16 01:04:02 WST 2009
> 12667 ?Ss 0:00 0 346 102733 50456 0.6
> /usr/bin/dbus-daemon --system
> 27136 pts/1S+ 0:00 0 101 4166 940 0.0 grep dbus
> r...
On Wed, 2009-07-15 at 13:14 +, Hei Ku wrote:
> Don't patronize me, please. I know that D-Bus shouldn't take 2GB of RAM
> and fill in all available swap space while sitting idle.
>
Then prove it is.
Scott
--
Scott James Remnant
sc...@canonical.com
--
dbus-daemon memory leak
https://bugs.la
On Wed, 2009-07-15 at 12:27 +, Hei Ku wrote:
> It renders the machine unusable, and it will even prevent me from
> restarting kdm. So, if it is not a memory leak, it behaves like one, and
> whether it is a memory leak or not is just semantics. The problem should
> be fixed. If it's an excessiv
13 matches
Mail list logo