Very high memory usage

I tried compiz --replace, which seemed to work (redrew all of my windows, messed up my workspaces), but resulted in two compiz processes running:

mdz 1827 1.3 18.1 2181580 557564 ? Dl Apr10 62:31 compiz
mdz 24782 2.8 0.7 347156 21592 pts/0 Sl 20:40 0:03 compiz --replace

and more continuous hard disk thrashing.

Then, the older compiz process actually started to consume *more* resident memory:

mdz 1827 1.3 24.0 2181580 738676 ? Dl Apr10 62:32 compiz

at which point I tried to strace it to see what was going on:

perseus:[~] strace -p 1827
Process 1827 attached - interrupt to quit
+++ killed by SIGSEGV (core dumped) +++

Note, this is with a classic desktop (not Unity)

Thanks Matt,
We are aware that in some case, compiz --replace doesn't kill the older compiz process (there is no evidence when this happen unfortunately).
We are looking for memory leak in unity, but if you see some in compiz itself as well, we should have a look there. Did you notice any particular action triggering this memory leak?

(adding the unity task to be tracked by Sam in the dx team)

The task for tracking the memory leak is https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/758248

On Thu, Apr 14, 2011 at 07:29:23AM -0000, David Barth wrote:
> The task for tracking the memory leak is
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/758248

Are you saying that's believed to be the same issue, even though 758248 is
with Unity and my bug is with classic?

--
 - mdz

On Thu, Apr 14, 2011 at 07:21:41AM -0000, Didier Roche wrote:
> We are aware that in some case, compiz --replace doesn't kill the older
> compiz process (there is no evidence when this happen unfortunately).

Is there a bug open for that issue?

> We are looking for memory leak in unity, but if you see some in compiz
> itself as well, we should have a look there. Did you notice any particular
> action triggering this memory leak?

No particular action, no. After reporting this bug, I watched a DVD last
night, and then suspended my laptop (after stopping the film).

After resuming this morning, I see:

mdz 24782 1.2 8.0 578848 245560 pts/0 Sl Apr13 9:09 compiz --replace

and the memory usage is creeping up quickly without any explicit WM action from
me:

perseus:[~] while sleep 1; do date; ps u 24782; done
Thu Apr 14 09:19:42 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579732 246400 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:43 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579876 246440 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:44 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579796 246456 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:45 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579780 246476 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:46 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579888 246488 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:47 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579888 246488 pts/0 Sl Apr13 9:11 compiz --replac
Thu Apr 14 09:19:48 BST 2011
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
mdz 24782 1.2 8.0 579888 246500 pts/0 Sl Apr13 9:11 compiz --replac

--
 - mdz

Note that because compiz crashed previously when I straced it, I have a core dump which could be used for analysis if that's helpful.

Sure, can you upload to core dump in case we can have a look

The other bug mentioned by David is a global valgrind run for compiz and we only track the Nux mem leak fix in it.

On the --replace where older compiz process doesn't stop, there is no bug tracking it. We just experienced that within the team (and should not impact normal users as compiz is only restarted by gnome-session after a crash). Sam had a look at it last week IIRC without founding particular evidence of the issue (and we are prioritizing other more "main usage" bugs).

Matt, can you detail the applications that you used prior to suspending the system:
- was that totem playing the DVD or another one?
- where you using firefox or chromium (with version differences if not using the standard natty load)
- any other graphical application, apart from the browser, that would have a lot of stacked windows?

Was you browser open with a high number of windows or tabs? >50 > 100?

The compiz --replace issue is bug 760480

On Thu, Apr 14, 2011 at 08:40:12AM -0000, Didier Roche wrote:
> Sure, can you upload to core dump in case we can have a look

What's the best way to share it with you? I'm not keen to attach publicly
it in Launchpad as it could contain personal data.

> The other bug mentioned by David is a global valgrind run for compiz and
> we only track the Nux mem leak fix in it.

OK, so since this bug occurs without unity, it's a separate issue.

> On the --replace where older compiz process doesn't stop, there is no
> bug tracking it. We just experienced that within the team (and should
> not impact normal users as compiz is only restarted by gnome-session
> after a crash). Sam had a look at it last week IIRC without founding
> particular evidence of the issue (and we are prioritizing other more
> "main usage" bugs).

I will file a bug about this then.

--
 - mdz

On Thu, Apr 14, 2011 at 08:57:39AM -0000, David Barth wrote:
> Matt, can you detail the applications that you used prior to suspending the system:
> - was that totem playing the DVD or another one?

VLC

> - where you using firefox or chromium (with version differences if not using the standard natty load)

Chromium, one window with about 20 tabs

> - any other graphical application, apart from the browser, that would have a lot of stacked windows?

I don't think so, but I'll attach a dump of all running processes in my session.

--
 - mdz

It's continuing to steadily leak memory throughout the morning:

mdz 24782 1.2 7.1 625616 218084 pts/0 Sl Apr13 10:25 compiz --replace

Soon I will need to shut it down again. I will try closing applications and killing processes to see if there is any effect on the leak.

- Closing Chromium had no effect, the leak continues at a similar rate

- Switching workspaces seems to make it go faster (but this is hard to
  measure objectively)

- Closing Gwibber had no effect

- Closing all open Nautilus windows had no effect

- Closing all open Empathy windows had no effect

- Closing Skype had no consistent effect (it seemed to slow down for a bit
  but then resumed)

- Closing LibreOffice had no effect

- Closing XChat had no effect

Now I'm down to only terminal windows and it's still leaking away.

--
 - mdz

On 04/14/2011 11:08 AM, Matt Zimmerman wrote:
> On Thu, Apr 14, 2011 at 08:40:12AM -0000, Didier Roche wrote:
>> Sure, can you upload to core dump in case we can have a look
> What's the best way to share it with you? I'm not keen to attach publicly
> it in Launchpad as it could contain personal data.
Can bzip2 and share it with me via U1? and i'll distribute to
appropriate developers it we need to analyse that at this level.

David

I've rebooted into a fresh session, and have been monitoring compiz to see if anything triggers the problem. Nothing so far:

reboot and login
- memory usage stable
switch desktops
- goes up a small amount
- stabilizes again
suspend
resume
- memory usage stabilizes
switch desktops a lot
- stays stable
opened xchat-gnome
- small increase, stabilized
opened chromium
- very small increase, stable
opened nautilus
- moderate increase, stable
open VLC and play a DVD
- very small increase, stable
fullscreen VLC
- very small increase, stable
- mdz 1801 1.5 0.6 280488 20800 ? Sl 10:27 0:10 compiz
opened gwibber
- very small increase, stable
various ordinary work
- mdz 1801 1.5 0.6 281680 21412 ? Sl 10:27 0:17 compiz
more ordinary work, played a video in Youtube
- mdz 1801 1.5 0.7 281864 21656 ? Sl 10:27 0:34 compiz
more ordinary work, started Empathy
- mdz 1801 1.5 0.7 281936 21756 ? Sl 10:27 0:40 compiz

After almost an hour of normal work, including a suspend/resume cycle, memory usage is still normal and steady.

On 04/14/2011 11:22 AM, Matt Zimmerman wrote:
> - Closing Chromium had no effect, the leak continues at a similar rate
>
> - Switching workspaces seems to make it go faster (but this is hard to
> measure objectively)
>
> - Closing Gwibber had no effect
>
> - Closing all open Nautilus windows had no effect
>
> - Closing all open Empathy windows had no effect
>
> - Closing Skype had no consistent effect (it seemed to slow down for a bit
> but then resumed)
>
> - Closing LibreOffice had no effect
>
> - Closing XChat had no effect
>
> Now I'm down to only terminal windows and it's still leaking away.
Thanks for all the info.

I've looked into the precess list and find no obvious reason either. Can
you check the list of plugins you have enabled?

gconftool-2 -R /apps/compiz-1

@David: the list is available through my apport compiz hook:

See:
CompizPlugins: [core,bailer,detection,composite,opengl,decor,compiztoolbox,move,regex,grid,imgpng,vpswitch,resize,animation,workarounds,mousepoll,snap,gnomecompat,place,wall,session,expo,ezoom,staticswitcher,fade,scale]

and GconfCompiz.txt

On 04/14/2011 12:29 PM, Matt Zimmerman wrote:
> ** Attachment added: "compiz gconf settings"
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/760161/+attachment/2033614/+files/compiz-gconf.txt
Thanks.

The main difference i can spot, is that you have the imgpng plugin
active, whereas i don't.

Then it may be down to some particular options like mipmapping.

You do have mipmapping enabled in the switcher plugin, whereas we've
turned that to 'disable' by default to avoid GL issues with certain drivers.

Can you try disabling both to see if that has an effect on the speed at
which the leak happens?

I'm moving this bug to the backlog, until more elements can help confirm a way to reproduce the anomaly.

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

this was closed by mistake, setting it back to incomplete.

[Expired for compiz (Ubuntu) because there has been no activity for 60 days.]

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

[Expired for compiz (Ubuntu) because there has been no activity for 60 days.]

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]