Closed Bug 937078 Opened 11 years ago Closed 9 years ago

Intermittent aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions. Due to negative "gfx-quartz-surface" value.

Categories

(Toolkit :: about:memory, defect)

Product:
Toolkit
Component:
about:memory
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure) 

Rev4 MacOSX Lion 10.7 mozilla-inbound debug test mochitest-other on 2013-11-10 15:00:42 PST for push c0e8bbe5e71d

https://tbpl.mozilla.org/php/getParsedLog.php?id=30398118&full=1&branch=mozilla-inbound


14997 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions.

and from the logs the assertion seems to be:

15:17:32     INFO -  [Parent 1266] ###!!! ASSERTION: Invalid value (-4796 / -4796) for gfx-surface-quartz: 'false', file aboutMemory.js, line 0
> 15:17:32     INFO -  [Parent 1266] ###!!! ASSERTION: Invalid value (-4796 /
> -4796) for gfx-surface-quartz: 'false', file aboutMemory.js, line 0

The "gfx-surface-quartz" reporter is known to be buggy -- it occasionally gives negative values.  It was reported in bug 899312, but I'll dup that bug to this one, since this failure is likely to occur repeatedly on Mac until it's fixed.
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions. → Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions. Due to negative "gfx-quartz-surface" value.
Have I mentioned that I don't like counter-based reporters, because they are error-prone?
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/components/aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions. Due to negative "gfx-quartz-surface" value. → Intermittent aboutmemory/tests/test_aboutmemory5.xul | Assertion count 1 is greater than expected range 0-0 assertions. Due to negative "gfx-quartz-surface" value.
The negative reported value is gSurfaceMemoryUsed[gfxSurfaceTypeQuartz].

It is updated by RecordMemoryUsedForSurfaceType(aType, aBytes), with
aType==gfxSurfaceTypeQuartz.  |aBytes| can be positive or negative;  we must be
making calls whose |aBytes| values, in sum, are negative.

The two places that call RecordMemoryUsedForSurfaceType() are
RecordMemoryUsed() (positive |aBytes| values) and RecordMemoryFreed() (negative
|aBytes| values).

The use of |mBytesRecorded| makes it look like it shouldn't be possible to end
up with a negative value -- the only negative |aBytes| value is
-mBytesRecorded, and that should always be balanced by earlier positive values.

My best theory right now:  we use GetType() to get the |aType| parameter, which
looks like this:

    gfxSurfaceType
    gfxASurface::GetType() const
    {
        if (!mSurfaceValid)
            return (gfxSurfaceType)-1;

        return (gfxSurfaceType)cairo_surface_get_type(mSurface);
    }

If the surface type can change (either within Cairo, or because mSurfaceValid
changes) that would cause addition/subtraction mismatches.  In particular, the
type would need to change from non-Quartz to Quartz to explain the negative
value.

I added some assertions to check for this and didn't hit anything, but this
problem doesn't reproduce reliably.
I get this frequently locally in my normal session if I can help in some way.
mccr8, can you try running with the patch at https://hg.mozilla.org/try/rev/d81442826579 applied?  I just did over 100 retriggers of Mochitest-o on try but didn't hit this failure once :(
Flags: needinfo?(continuation)
Sorry it has taken me so long to get to this, Nick.  Also, I upgraded OSX 10.9 so it seems to happen less now, but it does still happen, so I'll take your patch for a spin.  What am I looking for here, just a stack it asserts on or something?
(In reply to Andrew McCreight [:mccr8] from comment #17)
> Sorry it has taken me so long to get to this, Nick.  Also, I upgraded OSX
> 10.9 so it seems to happen less now, but it does still happen, so I'll take
> your patch for a spin.  What am I looking for here, just a stack it asserts
> on or something?

Actually, if you can change this:

 MOZ_ASSERT(mType == GetType());

to something like this:

 if (mType != GetType()) {
   fprintf(stderr, "ARGH: %d, %d\n", mType, GetType());
   MOZ_CRASH();
 }

You'll get more useful info.

Thanks!
Sorry, I don't really see this error any more.  Maybe you should just land the patch, now that this is happening again and try to get some information out of the failing TBPL runs?
Flags: needinfo?(continuation)
I've been running into multiple failures where my FF-28/OSX.6.8 goes running away with memory (or so it seems) and only now have I gotten annoyed enough to look into it.

I'm inclined to open lots of tabs on lots of desktops and I always assumed I was doing something wrong until I started to watch the about:memory page which is when I saw the gfx-surface-quartz errors.

From a user's point of view, if we had some idea what anyone *thinks* is triggering this we could pay more attention to it.

In an effort to be helpful, I've gone and collected lots and lots of data for "you". I kept doing the "measure" with the verbose flag and lots of "Save memory reports" to disk until I saw the error occur (which I just did.) the collection of files is ~15MB and all zipped up if anyone wants to look.

I also used the "support information" page to save the configuration info a few times just to make sure.

So, if these logs are of any value, please let me know and I'll make them available to you via dropbox. (Because I'm not sure of how secure posting logs into the bugzilla is and since it may contain information I'm not fond of sharing, I opted to do this. Any advice on that would be welcome.)

Thanks for everyone's time!
Would you mind having a look at the data from comment 109 if it is of any value?
Flags: needinfo?(continuation)
Yeah, I saw that comment when it was posted, but unfortunately I don't this an about:memory report will be very useful.  njn had some ideas for an instrumented build to try to figure out what might be happening, so if anybody can regularly reproduce this problem that would be useful.
Flags: needinfo?(continuation)
(In reply to Andrew McCreight [:mccr8] from comment #113)
> Yeah, I saw that comment when it was posted, but unfortunately I don't this
> an about:memory report will be very useful.

Thanks for your comment. I seem to be suffering from having too much blood in my caffeine system so I am guessing what you said here. I have LOTS of data collected in my logs which I'll give you but I am not sure of the security here so I will send you a link via email to get to the logs directly.

Contact me directly. Michael(dot)Tiernan(at)gMail

Thanks for everyone's time.

As for "regularly reproduce this problem", I might be as close to that as is possible. I can, within about an hour trigger the failure /usually/.

If there's a way to increase the logging verbosity, let me know and I'll do that and try again.
Now that I see your email address, I'll send you the link right now.
Oops, I meant "I don't think an about:memory report will be very useful.".  Anyways, Nick is a better person to ask about what might be the right thing to do here.
Flags: needinfo?(n.nethercote)
To make progress here we need someone who can reliably reproduce this to apply a custom diagnostic patch, rebuild Firefox, and then run with the patch.
Flags: needinfo?(n.nethercote)
(In reply to Nicholas Nethercote [:njn] from comment #117)
> To make progress here we need someone who can reliably reproduce this to
> apply a custom diagnostic patch, rebuild Firefox, and then run with the patch.

I will offer to run and reproduce the error but I have not set up the build environment to even experiment/play with much less to run patches against.

If someone wants to the the blacksmith part of it I'll do the test & run.
Nick could do a try push with the patches he's interested in, which would let other people try it out locally.
I'm getting this error as well (I'm on Mavericks, if that information is useful). Much like Michael, if someone builds FF with the patch, I'd be happy to test it and provide another data point.
Happens almost every time to me on Mac OS X 10.6.8. Guess everyone already reported what may be useful, but if you need some feedback I'm glad to contribute.
I usually have from 3 to 10 tabs opened at once and Firefox itself uses around 800MB of RAM (in this conditions my 2GB of ram available are often fullfilled also by other programs). Is such an amount of consumed memory normal?
> I usually have from 3 to 10 tabs opened at once and Firefox itself uses
> around 800MB of RAM (in this conditions my 2GB of ram available are often
> fullfilled also by other programs). Is such an amount of consumed memory
> normal?

It varies a lot depending on which sites you have open and which add-ons you have installed, but it doesn't sound excessive.
Inactive; closing (see bug 1180138).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.