Closed Bug 1555457 Opened 10 months ago Closed 8 months ago

Assertion failure: aSize.width >= 0.0 && aSize.height >= 0.0, at src/layout/base/nsLayoutUtils.cpp:8832


(Core :: Layout, defect, P3)




Tracking Status
firefox69 --- affected


(Reporter: tsmith, Unassigned)


(Blocks 1 open bug)


(Keywords: assertion, testcase)


(1 file)

Attached file testcase.html

This test case only repros on Android.

Assertion failure: aSize.width >= 0.0 && aSize.height >= 0.0, at src/layout/base/nsLayoutUtils.cpp:8832

eip = 0xc790a718   esp = 0xcd7fddf0   ebp = 0xcd7fde68   ebx = 0xccbdcdc8
esi = 0x00002280   edi = 0xaf804e50   eax = 0xca58015b   ecx = 0xcdc3617c
edx = 0x00000094   efl = 0x00210282
OS|Android|0.0.0 Linux 4.4.124+ #1 SMP PREEMPT Wed Jan 30 07:13:09 UTC 2019 i686
CPU|x86|GenuineIntel family 6 model 6 stepping 3|4
13|0||nsLayoutUtils::SetVisualViewportSize(mozilla::PresShell*, mozilla::gfx::SizeTyped<mozilla::CSSPixel, float>)||8832|0x22
13|1||mozilla::GeckoMVMContext::SetVisualViewportSize(mozilla::gfx::SizeTyped<mozilla::CSSPixel, float> const&)||135|0x1c
13|2||MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&)||437|0x19
13|3||MobileViewportManager::UpdateResolution(nsViewportInfo const&, mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::SizeTyped<mozilla::CSSPixel, float> const&, mozilla::Maybe<float> const&, MobileViewportManager::UpdateType)||402|0x13
13|5||mozilla::PresShell::ResizeReflow(int, int, int, int, mozilla::ResizeReflowOptions)||1856|0x15
13|6||nsViewManager::DoSetWindowDimensions(int, int)||182|0x20
13|10||nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp)||1979|0x14
13|11||mozilla::RefreshDriverTimer::TickRefreshDrivers(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&)||349|0x33
13|12||mozilla::RefreshDriverTimer::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp)||342|0x53
13|13||mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp)||709|0x41
13|15||nsThread::ProcessNextEvent(bool, bool*)||1176|0x16
13|16||NS_ProcessNextEvent(nsIThread*, bool)||486|0x11
13|23||XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&)||4688|0x8
13|24||XRE_main(int, char**, mozilla::BootstrapConfig const&)||4769|0xf
13|26||mozilla::BootstrapImpl::GeckoStart(_JNIEnv*, char**, int, mozilla::StaticXREAppData const&)||77|0x11
Flags: in-testsuite?
Flags: needinfo?(hikezoe)

Hmm I can't reproduce the assertion locally on Android emulators. We bail out early somewhere?

Flags: needinfo?(hikezoe)
Priority: -- → P3

The call stack looks identical the one in bug 1548896.

Brad, this should be fixed bug 1548896, right?

Flags: needinfo?(bwerth)

Those callstacks do look identical to me. I can't explain how this bug is happening. The code changed by Bug 1548896 should resolve this. It seems clear that MobileViewportManager::UpdateVisualViewportSize is not allowed to return a negative size, since MobileViewportManager::GetCompositionSize now only returns non-negative sizes. Is it possible that this test was done with an earlier Android build that didn't have the code that landed in Bug 1548896?

Flags: needinfo?(bwerth)

Thank you, Ting-Yu and Brad.
Hey Tyson, which revision did you use in comment 0? Are you still able to reproduce the assertion on the latest m-c?

Flags: needinfo?(twsmith)

The report is from m-c 20190529-2bb77ed1fcc5. I can reproduce it consistently.

Flags: needinfo?(twsmith)

(In reply to Alexandru Michis [:malexandru] from comment #8)

Tyson, any updates regarding this?

Not sure what else to say here... did I miss something?

Flags: needinfo?(twsmith) → needinfo?(malexandru)

We should ask Brad instead.

Flags: needinfo?(malexandru) → needinfo?(bwerth)
Duplicate of this bug: 1566824
See Also: → 1568405

Note, I'm chasing this down a bit (gathering more info at least by adding earlier assertions) in bug 1566991 and bug 1568673.

The former bug (which landed yesterday) added an assertion that seems to be catching this problem a bit earlier (and it seems to have done so, e.g. in newly-filed intermittent bug 1568405). I suspect that any intermittent failures that would have been reported here will now instead appear on bug 1568405 (and soon perhaps on a new bug for the new assertion I'm adding in bug 1568673).

So: this bug here might go "quiet" in terms of treeherder failure reports, but it's likely that the problem will have just been caught earlier (via an assertion with different text).

Also: it's notable that we've hit this assertion on Android (comment 0 w/ the fuzzer testcase) and MacOS (the intermittent reports), the two platforms where we have overlay scrollbars. I suspect overlay scrollbars are involved in causing trouble here.

(In reply to Daniel Holbert [:dholbert] from comment #13)

Note, I'm chasing this down a bit (gathering more info at least by adding earlier assertions) in bug 1566991 and bug 1568673.

Okay, if zoom can become negative (is this ever useful?) then my patches in Bug 1548896 are not adequate to solve this. I'll see if I can understand the call stack in Bug 1568405 which is generating the negative zoom values. I propose that this should be closed as a duplicate of that bug.

Flags: needinfo?(bwerth)

Tyson, would you mind seeing if you can still reproduce this with your attached testcase?

(Based on comment 1 / comment 4, I'm guessing that I [like hiro] might not be able to repro, but you probably have the right environment to reproduce with your testcase.)

I'm guessing bug 1569475's patch may have fixed this. (Or rather, converted into an earlier nonfatal assert with sane fallback behavior.)

Flags: needinfo?(twsmith)

I am no longer able to reproduce this with m-c:

Flags: needinfo?(twsmith)

Great, thanks Tyson!

Calling this WORKSFORME since I wouldn't claim to be 100% sure what fixed it (though I'd bet it was bug 1569475).

Closed: 8 months ago
Resolution: --- → WORKSFORME

Note: recent failure-robot starrings are all from mozilla-release and mozilla-beta, which is consistent with this having been fixed on central as of comment 18.

(One exception: comment 20 has a starring for mozilla-central from after this was fixed -- but that seems to have been an incorrect association. I don't see any instance of this bug's assertion-failure in the verbose log there.)

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