1253838 - Permanent WinXP e10s layout/generic/crashtests application crashed [@ mozilla::ContainerState::ProcessDisplayItems(nsDisplayList *)]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Not sure if this is XP-specific or due to lack of hardware acceleration.

https://treeherder.mozilla.org/logviewer.html#?job_id=17670517&repo=try

22:19:51     INFO -  REFTEST TEST-START | file:///C:/slave/test/build/tests/reftest/tests/layout/forms/crashtests/498698-1.html
22:19:51     INFO -  REFTEST TEST-LOAD | file:///C:/slave/test/build/tests/reftest/tests/layout/forms/crashtests/498698-1.html | 1572 / 3012 (52%)
22:19:51     INFO -  ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0077,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
22:19:51     INFO -  JavaScript error: resource://app/modules/ContentCrashHandlers.jsm, line 75: TypeError: browser.permanentKey is not a non-null object
22:25:21     INFO -  REFTEST ERROR | file:///C:/slave/test/build/tests/reftest/tests/layout/forms/crashtests/498698-1.html | application timed out after 330 seconds with no output
22:25:21     INFO -  REFTEST TEST-INFO | started process screenshot
22:25:22     INFO -  REFTEST TEST-INFO | screenshot: exit 0
22:25:22     INFO -  TEST-INFO | crashinject: exit 0
22:25:22  WARNING -  TEST-UNEXPECTED-FAIL | file:///C:/slave/test/build/tests/reftest/tests/layout/forms/crashtests/498698-1.html | application terminated with exit code 1
22:25:22     INFO -  REFTEST INFO | Copy/paste: C:\slave\test\build\win32-minidump_stackwalk.exe c:\docume~1\cltbld~1.t-x\locals~1\temp\tmpdq_69c.mozrunner\minidumps\b9874a4d-3153-4e55-a15a-2825cacc3c45.dmp C:\slave\test\build\symbols
22:25:37     INFO -  REFTEST INFO | Saved minidump as C:\slave\test\build\blobber_upload_dir\b9874a4d-3153-4e55-a15a-2825cacc3c45.dmp
22:25:37     INFO -  REFTEST INFO | Saved app info as C:\slave\test\build\blobber_upload_dir\b9874a4d-3153-4e55-a15a-2825cacc3c45.extra
22:25:37    ERROR -  REFTEST PROCESS-CRASH | file:///C:/slave/test/build/tests/reftest/tests/layout/forms/crashtests/498698-1.html | application crashed [@ mozilla::ContainerState::ProcessDisplayItems(nsDisplayList *)]
22:25:37     INFO -  Crash dump filename: c:\docume~1\cltbld~1.t-x\locals~1\temp\tmpdq_69c.mozrunner\minidumps\b9874a4d-3153-4e55-a15a-2825cacc3c45.dmp
22:25:37     INFO -  Operating system: Windows NT
22:25:37     INFO -                    5.1.2600 Service Pack 3
22:25:37     INFO -  CPU: x86
22:25:37     INFO -       GenuineIntel family 6 model 30 stepping 5
22:25:37     INFO -       8 CPUs
22:25:37     INFO -  Crash reason:  EXCEPTION_BREAKPOINT
22:25:37     INFO -  Crash address: 0x11fb0317
22:25:37     INFO -  Assertion: Unknown assertion type 0x00000000
22:25:37     INFO -  Process uptime: 303 seconds
22:25:37     INFO -  Thread 0 (crashed)
22:25:37     INFO -   0  xul.dll!mozilla::ContainerState::ProcessDisplayItems(nsDisplayList *) [FrameLayerBuilder.cpp:b3b07c447281 : 4163 + 0x22]
22:25:37     INFO -      eip = 0x11fb0317   esp = 0x0012dd74   ebp = 0x0012e0cc   ebx = 0x0012e101
22:25:37     INFO -      esi = 0x00001043   edi = 0x0ac2f1e0   eax = 0x13bc48b0   ecx = 0x016b0ad9
22:25:37     INFO -      edx = 0x01770ea0   efl = 0x00200206
22:25:37     INFO -      Found by: given as instruction pointer in context
22:25:37     INFO -   1  xul.dll!mozilla::FrameLayerBuilder::BuildContainerLayerFor(nsDisplayListBuilder *,mozilla::layers::LayerManager *,nsIFrame *,nsDisplayItem *,nsDisplayList *,mozilla::ContainerLayerParameters const &,mozilla::gfx::Matrix4x4Typed<mozilla::gfx::UnknownUnits,mozilla::gfx::UnknownUnits> const *,unsigned int) [FrameLayerBuilder.cpp:b3b07c447281 : 5277 + 0x11]
22:25:37     INFO -      eip = 0x11f9e32d   esp = 0x0012e0d4   ebp = 0x0012e330
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   2  xul.dll!nsDisplayList::PaintRoot(nsDisplayListBuilder *,nsRenderingContext *,unsigned int) [nsDisplayList.cpp:b3b07c447281 : 1697 + 0x2c]
22:25:37     INFO -      eip = 0x11ff15cf   esp = 0x0012e338   ebp = 0x0012e55c
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   3  xul.dll!nsLayoutUtils::PaintFrame(nsRenderingContext *,nsIFrame *,nsRegion const &,unsigned int,unsigned int) [nsLayoutUtils.cpp:b3b07c447281 : 3469 + 0x20]
22:25:37     INFO -      eip = 0x1202c5c1   esp = 0x0012e564   ebp = 0x0012eef4
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   4  xul.dll!PresShell::Paint(nsView *,nsRegion const &,unsigned int) [nsPresShell.cpp:b3b07c447281 : 6063 + 0xd]
22:25:37     INFO -      eip = 0x1202b583   esp = 0x0012eefc   ebp = 0x0012f00c
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   5  xul.dll!nsViewManager::ProcessPendingUpdatesPaint(nsIWidget *) [nsViewManager.cpp:b3b07c447281 : 467 + 0x1c]
22:25:37     INFO -      eip = 0x11d96286   esp = 0x0012f014   ebp = 0x0012f04c
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   6  xul.dll!nsViewManager::ProcessPendingUpdatesForView(nsView *,bool) [nsViewManager.cpp:b3b07c447281 : 398 + 0x9]
22:25:37     INFO -      eip = 0x11d9610d   esp = 0x0012f054   ebp = 0x0012f06c
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   7  xul.dll!nsViewManager::ProcessPendingUpdates() [nsViewManager.cpp:b3b07c447281 : 1100 + 0xc]
22:25:37     INFO -      eip = 0x11d95fcc   esp = 0x0012f074   ebp = 0x0012f2a8
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   8  xul.dll!nsRefreshDriver::Tick(__int64,mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 1893 + 0x12]
22:25:37     INFO -      eip = 0x11f9264e   esp = 0x0012f084   ebp = 0x0012f2a8
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -   9  xul.dll!mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver *,__int64,mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 274 + 0x1b]
22:25:37     INFO -      eip = 0x11f928d1   esp = 0x0012f2b0   ebp = 0x0012f2d8
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  10  xul.dll!mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64,mozilla::TimeStamp,nsTArray<RefPtr<nsRefreshDriver> > &) [nsRefreshDriver.cpp:b3b07c447281 : 246 + 0x19]
22:25:37     INFO -      eip = 0x11f92afc   esp = 0x0012f2e0   ebp = 0x0012f314
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  11  xul.dll!mozilla::RefreshDriverTimer::Tick(__int64,mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 265 + 0x1e]
22:25:37     INFO -      eip = 0x11f91b3f   esp = 0x0012f31c   ebp = 0x0012f34c
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  12  xul.dll!mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 588 + 0x16]
22:25:37     INFO -      eip = 0x11f91047   esp = 0x0012f354   ebp = 0x0012f3a8
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  13  xul.dll!mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 508 + 0x15]
22:25:37     INFO -      eip = 0x11f92aa3   esp = 0x0012f3b0   ebp = 0x0012f404
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  14  xul.dll!mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::NotifyVsync(mozilla::TimeStamp) [nsRefreshDriver.cpp:b3b07c447281 : 425 + 0x14]
22:25:37     INFO -      eip = 0x11f8feae   esp = 0x0012f40c   ebp = 0x0012f438
22:25:37     INFO -      Found by: call frame info
22:25:37     INFO -  15  xul.dll!mozilla::layout::VsyncChild::RecvNotify(mozilla::TimeStamp const &) [VsyncChild.cpp:b3b07c447281 : 64 + 0x18]
22:25:37     INFO -      eip = 0x12188862   esp = 0x0012f440   ebp = 0x0012f460
22:25:37     INFO -      Found by: call frame info

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Skipping 498698-1.html just moved the failure to 499885-1.xhtml.

Comment 2

[Tracy Walker [:tracy]]

I believe this is either a dupe of, or blocked by, bug 1141089?

Comment 3

[Timothy Nikkel (:tnikkel)]

Being reproducible makes this bug notable over bug 1141089 though.

Comment 4

[Markus Stange [:mstange]]

Extremely notable!

Comment 5

[Markus Stange [:mstange]]

Oh, this seems to be a completely different assertion than the one we're looking for in bug 1141089.

The failing assertion in this test run is at FrameLayerBuilder.cpp:b3b07c447281 : 4163 ( https://hg.mozilla.org/try/file/b3b07c447281/layout/base/FrameLayerBuilder.cpp#l4163 ):

MOZ_ASSERT(nsIntRegion(itemDrawRect).Contains(opaquePixels));

Which is not all that exciting.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Jet, is there anyone on your team with the cycles to look at this? It's one of the few remaining e10s permafails still affecting WinXP in CI.

Comment 7

[Jet Villegas (inactive)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #1)
> Skipping 498698-1.html just moved the failure to 499885-1.xhtml.

Both bug 498698 and bug 499885 are crash (assert) bugs that went into the tree with no actual code fixes. Both tests set large integer values for CSS units. We may need to add better clamping before such values make it past the style system into the displayList.

Comment 8

[Cameron McCormack (:heycam)]

Yeah, seems likely we need some clamping somewhere, though hopefully the computed values that the style system generates for those large lengths are already clamped to nscoord_MAX.  Interesting that both crashes are <select>s.

Comment 9

[Jet Villegas (inactive)]

The code is throwing CRAZY_SIZE asserts in BeginLineReflow() and XP seems more prone to crashing here. Markus: can you help plug this one?

Comment 10

[Markus Stange [:mstange]]

Looking.

Comment 11

[Markus Stange [:mstange]]

Pushed a try run with more debugging info: https://treeherder.mozilla.org/#/jobs?repo=try&revision=45cf8d4fe0c7

Comment 12

[Ryan VanderMeulen [:RyanVM]]

FYI, that e10s force-enable patch might not work correctly anymore due to the recent changes that made e10s the default for most test suites (I can't remember for sure which ones got broken). If so, https://hg.mozilla.org/try/rev/1c9c5cb550bdedc68be56e0bae0b712d791c999f is what you'll want to use instead.

Comment 13

[Markus Stange [:mstange]]

Pushed with that patch just to be sure: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c3b752e4c051

Comment 14

[Markus Stange [:mstange]]

Uhh, looks like my test was unsuccessful. The first push failed to run any tests, as predicted, and the second didn't hit the assertion. It also didn't print any display list dumps.
Has this crash just gone away?

Comment 15

[Ryan VanderMeulen [:RyanVM]]

No, it's still happening as of today's merges to m-c.
https://treeherder.mozilla.org/#/jobs?repo=ash&filter-searchStr=xp%20debug%20crash

Comment 16

[Markus Stange [:mstange]]

Huh. The log in my push says "REFTEST INFO | Running with e10s: True", but when I look at the PIDs that get printed, there's only one (4028). It doesn't look like there's a content process.
Is it possible to schedule a true e10s crashtest job on try?

Comment 17

[Ryan VanderMeulen [:RyanVM]]

That's.....interesting. The patch you're using basically short-circuits the harness to enable e10s, which effectively is what'll happen when the "real" e10s jobs are invoked from buildbot.

But no, Ash is the only branch that has a concept of crashtest-e10s on WinXP.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

(In reply to Markus Stange [:mstange] from comment #16)
> Huh. The log in my push says "REFTEST INFO | Running with e10s: True", but
> when I look at the PIDs that get printed, there's only one (4028). It
> doesn't look like there's a content process.
> Is it possible to schedule a true e10s crashtest job on try?

Is that different from a production C-e10s run from m-c? I'm looking at a few logs now and it appears that only one PID is printing in those as well.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

I did a little more Try experimentation today and the conclusion appears to be that the requested information isn't getting properly dumped into the logs, not an issue with the job not actually being e10s. Ahal, any idea as to why the printf or display-list dumps aren't showing up in the crashtest logs? I'm wondering if this is fallout from the signed XPI changes.
https://hg.mozilla.org/try/rev/7e644f5240d907680f933fb9b124da27afb58c18

Comment 20

[Andrew Halberstadt [:ahal]]

Hm, I doubt it has anything to do with addon signing.. but it could be related to the switch to structured logging (bug 1034290). That landed around March 14th. I believe that anything that was previously printed to stdout should continue to get printed on stdout.. though it wouldn't be the first time my beliefs were wrong.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

This apparently went away on its own at some point while bug 1271657 was causing widespread WinXP debug bustage. Completely green on Ash now \m/. Markus theorizes that bug 1263192 might have fixed it, but we both felt that it probably wasn't worth trying to bisect the fix more conclusively.