Last Comment Bug 674074 - about:memory blank in presence of WebGL contexts
: about:memory blank in presence of WebGL contexts
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
: 674306 674427 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-25 15:11 PDT by Benoit Jacob [:bjacob] (mostly away)
Modified: 2011-07-27 11:58 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
unbreak WebGL about:memory (3.10 KB, patch)
2011-07-26 10:09 PDT, Benoit Jacob [:bjacob] (mostly away)
n.nethercote: review+
Details | Diff | Splinter Review

Description Benoit Jacob [:bjacob] (mostly away) 2011-07-25 15:11:30 PDT
This seems to be a recent regression, since it worked fine when I initially landed WebGL about:memory support.

Steps to reproduce:
1. load a WebGL script in a tab
2. load about:memory in another tab

Result: about:memory is completely blank
Comment 1 Nicholas Nethercote [:njn] 2011-07-25 16:23:14 PDT
Bug 669611 added some sanity checking to aboutMemory.js.  If I open the error console on FOTN I see  "uncaught exception: assertion failed: elem._kind is not KIND_OTHER for webgl-buffer-cache-memory."

In WebGLContext.cpp three of the reporters have KIND_HEAP:  webgl-buffer-cache-memory, webgl-shader-sources-size, webgl-shader-translationlogs-size.  All the others have KIND_OTHER.

The comments in nsIMemoryReporter explain that KIND_HEAP reporters must have a path of the form "explicit/a/b".  Should these three reporters just be changed to KIND_OTHER?
Comment 2 Benoit Jacob [:bjacob] (mostly away) 2011-07-26 10:09:37 PDT
Created attachment 548511 [details] [diff] [review]
unbreak WebGL about:memory

Since these really are heap memory measurements, I kept KIND_HEAP and used "explicit/..." names as you suggested. That works. Also, I like that they're hidden by default as they're small: in this way, they don't clutter the view as they used to but if eventually one becomes big, it will show up.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-07-26 12:02:35 PDT
*** Bug 674306 has been marked as a duplicate of this bug. ***
Comment 4 Nicholas Nethercote [:njn] 2011-07-26 17:44:56 PDT
Comment on attachment 548511 [details] [diff] [review]
unbreak WebGL about:memory

Review of attachment 548511 [details] [diff] [review]:
-----------------------------------------------------------------

So the memory covered by the reporters is always on the heap, i.e. allocated with malloc/calloc/realloc/new/new[]?  And there's no overlap between the memory, i.e. no byte of memory is counted by more than one reporter?  This is ok if so.
Comment 5 Nicholas Nethercote [:njn] 2011-07-26 17:55:43 PDT
*** Bug 674427 has been marked as a duplicate of this bug. ***
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2011-07-26 21:19:16 PDT
> So the memory covered by the reporters is always on the heap, i.e. allocated
> with malloc/calloc/realloc/new/new[]?  And there's no overlap between the
> memory, i.e. no byte of memory is counted by more than one reporter?  This
> is ok if so.

Yes and yes, for the 3 KIND_HEAP reporters in question here. THere is no overlap, neither among these reporters nor between them and any other reporter.

The KIND_OTHER WebGL reporters, on the other hand, account for stuff not on the heap.
Comment 7 Nicholas Nethercote [:njn] 2011-07-26 21:35:11 PDT
Great!
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2011-07-27 11:58:29 PDT
http://hg.mozilla.org/mozilla-central/rev/15be41bf7150

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