From:  Eric Rahm <>
Date:  24 Mar 2016 06:14:33 Hong Kong Time

Re: MemShrink Pre-Triage (22nd Mar 2016)


Might miss the meeting today, my notes are below.

On Tue, Mar 22, 2016 at 6:16 PM, Eric Rahm <> wrote:

Please note our meeting time has changed. We meet March 23rd at 4PM PDT (aka March 24th at 10AM AEDT).

MemShrink triage: 2016-03-22

Triage URL:


(Add name and topic to discuss here)

Bug List

Vote for:

  • P1 High importance, will follow up periodically
  • P2 Important issue, possibly already being worked on
  • P3 Real issue, someone will get to it if they have time
  • moreinfo We need logs, or clarifying information
  • invalid Misclassified, remove the MemShrink tag

13 bugs to triage

  • 1232549 - Core :: Graphics - Win7/Win8 mochitest-2 permaleak of AsyncTransactionTrackersHolder, CompositableChild, CondVar, Mutex, PCompositableChild, ... on mozilla-aurora 45


P2? Seems like an e10s blocker that's been bugging us for a while. 
  • mccr8, what do you think?

  • 1252349 - Core :: Graphics: Layers - [e10s] Frequent IPC::Message (and sometimes SharedMemory) leaks during the dom/media tests on OSX


 P1? The leak isn't huge, but if it's cumulative this could be bad for long lived e10s sessions.
  • 1255826 - Firefox :: Untriaged - Firefox 64 leaks memory to an extent of 11GB+ even in safe mode


Maybe ni? the reporter, try to get the places.sqlite to someone who can debug the issue.  At this point it feels like a P2/P3.
  • mccr8, what do you think?

  • 1255844 - Core :: Plug-ins - plugin-container crashes my computer due to memory leak


This seems pretty bad, but is probably a plugin. I suppose it would help to get a link to the crash report?
  • 1255891 - Core :: Canvas: 2D - [e10s] imagebitmap canvas tests seem to leak an arbitrary amount of textures in Windows with e10s


  • mccr8, what do you think?

  • 1255998 - Tech Evangelism :: Add-ons - addon SDK leaks massively leads Firefox can't close web pages


This is on 42, weren't there some SDK leak fixes recently? Maybe ni? and see if they can repro on a newer version.
P1? Seems like we shouldn't let a (unintentionally) malicious page OOM us.
  • 1256946 - Core :: Graphics: Layers - test_video_wakelock.html leaks textures on Windows e10s debug builds


Defer to mccr8.
  • mccr8, what do you think?

  • 1257066 - Toolkit :: Startup and Profile System - Firefox 45.0 Slow Startup and very slow and very lagging. Using To Much RAM WIndows 10


moreinfo, ni'd the reporter.
  • 1257388 - Core :: ImageLib - Play back all animated images via the media framework


This sounds awesome, I'm leaning P1.
  • 1257486 - Toolkit :: Breakpad Integration - Crash report memory information not implemented for child processes (content processes)


    mccr8, what do you think?

  • 1258778 - Core :: Graphics - Purge the skia glyph cache when receiving a low memory notice


    erahm, what do you think?

This (and the following bug) are fallout from bug 1239151 where switching to a skia backend for content on OS X caused a talos regression, to fix that they bumped a glyph cache up to 10MiB per content process. This is obviously a bad thing for our multiple-content process work. It *does* have significant perf wins for non-latin character sets (think Chinese, etc) so I can understand the motivation.

To mitigate the impact I suggested we should be able to at least purge the cache which is what this bug does. I'll go with P2 here (it's already landed).
  • 1258781 - Core :: Graphics - Lower the skia glyph cache size when we have multiple content processes


So this is about scaling down the size of the cache when there are multiple content processes. I wonder if there's a better option, like sharing a cache across processes (this is essentially what CoreGraphics does at an OS level). If we think 10MiB is too much it would be worth pushing back in this bug, either way I think we should push for this to be done sooner than later as it will impact our ability to assess the memory overhead of multiprocess.

I'm leaning P2, but could see going with P1 to make sure it gets done.