New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 40 users
Status: Verified
Last visit > 30 days ago
Closed: Nov 2009
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment
about:memory doesn't work on OS X
Reported by, Apr 2 2009 Back to list
Chrome Version       : (Developer Build 12913)

What steps will reproduce the problem?
1. Build or download Chromium for Linux/Mac
2. Type about:memory in the address bar

What is the expected result?
On Windows, this results in detailed stats on the browser's memory usage.

What happens instead?
The debug console shows:

:ERROR:renderer/] Not implemented reached in
void renderer_logging::SetActiveRendererURL(const GURL&)

Labels: -OS-All -Area-Misc OS-Linux Area-BrowserBackend OS-Mac
Comment 2 by, Apr 3 2009
Status: Invalid
Sorry, too early to expect it to work.  Most bug reports for either of these two
ports will be rejected until we release a dev channel build.  There are simply too
many things left to implement.
Comment 3 by, Apr 3 2009
Oh, I filed this bug in conjunction with an email sent out to chromium-dev, based on
Mike Pinkerton's reply.

The main purpose of this is to track the development for this feature, rather than a
normal bug report. I'm starting work on this as a developer new to the project.

Status: Available
This was filed at my request. Please don't pre-triage bugs for us.
Comment 5 by, Apr 8 2009
Labels: Mstone-Linux
Comment 6 by, Apr 8 2009
Labels: Mstone-Mac
Comment 7 by, May 4 2009
Labels: Mstone-MacBeta
Removing the MStone:Mac label as this will no longer be used.  It is 
replaced with MStone:MacDev for issues that should be resolved before 
release to testers and the dev channel.  Mstone:MacBeta is for issues that 
should be resolved before the release of a public beta. 

The Mstone:MacBeta list needs to be triaged.  This issue may not be 
required for the Beta.  Any issues that are not required for the beta 
release could be moved to mstone:x where they can wait to be assigned to a 
Comment 8 by, May 15 2009
Labels: Mstone-LinuxDev
Comment 9 by, May 15 2009
Labels: -Mstone-LinuxDev
Labels: Mstone-X
I'd like to look into this one on Linux. Please assign to me.
 Issue 13797  has been merged into this issue.
Comment 13 by, Jun 15 2009
Status: Started
Marking started based on comment 11.
Comment 14 by, Jun 25 2009
Labels: Mstone-LinuxBeta
Comment 15 by, Jun 29 2009
I pinged #11 today and he is still working on it.
Labels: -Mstone-LinuxBeta Mstone-4
Not a beta blocker, but nice to have.
No, the ticket itself is not a beta blocker, but decreasing the memory usage is.

Otherwise having more than 4 tabs open will use considerably more memory than
Firefox, and you have seen the comparissons on the web where they trash Chrome based
onn memory usage, right?

I would optimize Chromium to use at least the same ammount of memory than Firefox
with 10 tabs open.
Comment 18 by, Jul 22 2009
amistry: ping.  Still working on this?
Yeah, but only on Linux. Someone else can take up the Mac part.  Also, I'm having 
trouble locating the VM private/shared information on Linux (it's not in procfs), any 
Comment 20 by, Jul 22 2009
+the OS twins for advice on comment #19
Comment 21 by, Jul 22 2009
(I thought I reviewed a change which already did all this.)

#19: what are you looking for? You can get rough data from smaps and a page-by-page 
breakdown in pagemap (although parsing pagemap is overkill for this).
I can get resident memory data from smaps, not virtual.  I'm on Ubuntu Hardy which 
doesn't have the pagemap file in proc (introduced in 2.6.25).
For interested onlookers, here is a code review for amistry's CL (I don't know if it's the only one):

Given Anand's comment about refactoring (which would touch the common code as well), any work on the Mac 
part should probably wait. (It's not like Apple's making it easy to get useful process information.)
(Mostly for my own reference....) On Mac, getting process information seems to be a case of picking your poison:
- the kern.proc sysctl (see sysctl(3)) doesn't provide much information (leaving many fields of the kinfo_proc 
structure zero)
- the Mach calls apparently require permissions (see TVL's comment under ProcessMetrics in 
base/; moreover, getting all the VM information would be quite involved
- libproc (see <libproc.h>) is an Apple-private interface which may (and I suspect will) change; apparently, there 
are already problems with (lack of) #pragma pack(4)'s on 64-bit in <sys/proc_info.h>
- running ps seems like a reasonable option, since it's well-standardized; however, it doesn't appear to offer 
information on shared memory size
- running top (in logging mode) is another option (providing more information about memory), but it doesn't let 
you pick out processes by PID; it's also very not-standardized and may change, possibly in incompatible ways
- there really are no good programmatic interfaces, at least as of August 2007: 
- one could take Apple's libtop <> (and .h), but 
this doesn't solve any problems (it's still using a private API, it still requires perms)

Maybe the "top" poison is the tastiest (that, or "ps").
A not-yet-ready-for-review (I'm waiting on refactoring) patch for the Mac side is here:
Comment 26 by, Sep 1 2009
Labels: -OS-Linux
Comment 27 by, Sep 2 2009
Labels: -mstone-4 mstone-5
Not a blocker for mstone-4 moving to mstone-5
Comment 28 by, Sep 2 2009
Summary: about:memory doesn't work on OS X (was: NULL)
In Chromium Mac build: (25313)

I got a crash when I tried about:memory. (All of Chromium crashed, not just the tab.) 
I'm attaching the dump.
58.1 KB View Download
Comment 30 by, Oct 21 2009
paradoxmo - this bug has gotten a little more stale.  I am unable to reproduce a 
crash with:

  Hostname: krisr-macbookpro.local
  Mac OS X Version 10.5.8 (Build 9L31a)
  Processor: 2 Intel 2.40 GHz
  RAM: 2048 MB

  Chrome version:  Release
  QuickTime Player: 7.6.2
  QuickTime PlayerX: <unknown>
  Flash Player:

If you do see a crash please file a new bug for that issue.
I'm working on (well, nearly finished) a patch which will provide about:memory on Mac. 
It won't be very good at measuring our own memory usage until we perform some more 
I can confirm it doesn't crash anymore, it just still doesn't work. Looking forward to 
seeing the patch from #31.
Comment 33 by, Nov 3 2009
 Issue 26571  has been merged into this issue.
Comment 34 by, Nov 3 2009
Blockedon: 25454
The following revision refers to this bug: 

r31168 | | 2009-11-05 15:37:40 -0800 (Thu, 05 Nov 2009) | 12 lines
Changed paths:

Mac: Implement about:memory.

This implements about:memory on Mac. It calls /bin/ps to obtain information
about processes (this is Apple's officially supported "API"). Unfortunately, ps
provides fairly minimal information (rss and vsize); top is better, but not a
stable API -- it has changed greatly between Mac OS 10.5 and 10.6, and moreover
the 10.6 version is more limited in its output formatting.

BUG= 9653 
TEST=Go to about:memory under a variety of conditions (with a variety of browsers loaded).

Review URL:

Blockedon: -25454
Status: Fixed
I'm going to mark this as "Fixed". We still need backend work to measure memory use 
well ( issue 25454 ). But (Mac) about:memory itself is implemented.
Comment 37 by, Nov 19 2009
Status: Verified r32475
Labels: -Area-BrowserBackend Area-Internals
Project Member Comment 39 by, Oct 12 2012
Blocking: -chromium:17851
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 40 by, Mar 10 2013
Labels: -mstone-5 -Area-Internals M-5 Cr-Internals
Project Member Comment 41 by, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment