Open Bug 922976 Opened 11 years ago Updated 2 years ago

Intermittent gfx/tests/crashtests/394751.xhtml | load failed: null

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Platform:
ARM
Android
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox26 --- disabled
firefox27 --- disabled

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Android and B2G][leave open])

Attachments

(1 file)

stack when nsParser::OnDataAvailable returns NS_ERROR_UNEXPECTED
(deleted), text/plain
Details
Android 2.2 Armv6 Tegra mozilla-inbound opt test crashtest on 2013-10-01 23:55:52 PDT for push e19ed60eaffa slave: tegra-117 https://tbpl.mozilla.org/php/getParsedLog.php?id=28659591&tree=Mozilla-Inbound REFTEST TEST-UNEXPECTED-FAIL | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml | load failed: null
http://mxr.mozilla.org/mozilla-central/source/gfx/tests/crashtests/394751.xhtml Nor sure what this means, it failed to load, this is the only info that the log shows: REFTEST INFO | Loading a blank page REFTEST TEST-END | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394246-2.html REFTEST TEST-START | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml REFTEST TEST-LOAD | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml | 2350 / 2525 (93%) REFTEST TEST-UNEXPECTED-FAIL | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml | load failed: null REFTEST INFO | Saved log: START http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml REFTEST INFO | Saved log: [CONTENT] AfterPaintListener in data:text/html;charset=UTF-8,%3C%21%2D%2DCLEAR%2D%2D%3E REFTEST INFO | Saved log: [CONTENT] AfterPaintListener in data:text/html;charset=UTF-8,%3C%21%2D%2DCLEAR%2D%2D%3E REFTEST INFO | Saved log: [CONTENT] AfterPaintListener in http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml REFTEST INFO | Saved log: [CONTENT] AfterPaintListener in http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml REFTEST INFO | Loading a blank page REFTEST TEST-END | http://10.250.49.161:30117/tests/gfx/tests/crashtests/394751.xhtml My guess is that this test somehow got into a state where it didn't finish loading, so the load event never fired?
Perhaps this can be can be reproduced on an Android 2.2 device? That the testcase url is not finishing loading there sometimes? https://bugzilla.mozilla.org/attachment.cgi?id=279448 (this is the testcase from bug 394751`). The first occurence of this failure is 2013-10-01 23:55:52 PDT on inbound and 2013-10-02 10:17:16 on mozilla-central. Maybe we can get an educated guess on what check-in might have caused this intermittent failure?
Try bisection confirms that this is a regression from bug 897162. Brian, can you please look into this? This is currently the #1 orange on trunk.
Blocks: 897162
Flags: needinfo?(bnicholson)
Summary: Intermittent TEST-UNEXPECTED-FAIL | tests/gfx/tests/crashtests/394751.xhtml | load failed: null → Intermittent gfx/tests/crashtests/394751.xhtml | load failed: null
Well, I'm not learning anything more here. Disabled on Tegras in http://hg.mozilla.org/integration/mozilla-inbound/rev/49c0ddcb6ad8
OS: Mac OS X → Android
Hardware: x86 → ARM
Whiteboard: [test disabled on Tegras][leave open]
I've been looking into this, but I honestly have no idea what's happening here. I can't reproduce this locally. I tried adding logging on try (https://tbpl.mozilla.org/?tree=Try&rev=a24caae3f3b5), but the log messages don't appear in the full log, so I assume parts of logcat are missing. Unfortunately, that makes this pretty tough to debug. We might be able to enable this test again if bug 925843 is fixed.
Flags: needinfo?(bnicholson)
Depends on: 925843
This fails intermittently on Android x86 emu also, as seen in Comment 262. I will disable it there as well.
As the vast majority of the recent history of bug 789751 shows, this also affects B2G. I'm going to go ahead and disable it there as well.
https://hg.mozilla.org/integration/mozilla-inbound/rev/534160ed14fc
Whiteboard: [test disabled on Tegras][leave open] → [test disabled on Android and B2G][leave open]
With that crashtest, onload seems to get fired erratically. Especially, when it is loaded the first time, the load event doesn't seem to get fired at all: http://people.mozilla.org/~mwargers/tests/intermittent/394751_parentframe.html Olli, shouldn't the load event fire at all times for this document?
Flags: needinfo?(bugs)
For what document? For the parent? But I don't think it is spec'ed properly what should happen in case of parsing errors.
Flags: needinfo?(bugs)
No, for the child documents, the parsing errors one. I think crashtest (reftest) framework relies on the load event to fire to trigger the next test. It surprises me that this test doesn't cause more failures, then.
Question: should crashtests rely on the test document to fire a load event? Because with 39471.xhtml, that doesn't always happen.
Flags: needinfo?(dholbert)
(In reply to Martijn Wargers [:mwargers] (QA) from comment #271) > Question: should crashtests rely on the test document to fire a load event? If by "should they rely on it" you mean "do they rely on it": yes, they do. (That's how the test knows that it's done.) I don't think that can change. If this test doesn't reliably send onload, maybe it should be loaded in an iframe? (and then the host document will (I think?) reliably fire a load event, even if the iframe doesn't. We'd probably need to use a setTimeout to give the iframe a chance to do whatever badness this crashtest is testing for, too.)
Flags: needinfo?(dholbert)
Fwiw, with the test in comment 268 I see a lot of (on Linux): ###!!! ASSERTION: no SHEntry for a non-transient viewer?: 'NS_IsAboutBlank(mCurrentURI)', docshell/base/nsDocShell.cpp, line 10926
I can reproduce the problem in a local debug build when loading the test from http://people.mozilla.org/~mwargers/tests/intermittent/394751_parentframe.html but not when I load a local copy of that test from http://localhost/ It may be timing issue of some sort.
If you run it with NSPR_LOG_MODULES=LoadGroup:5,nsStreamPump:5; you will see: -134449280[7ffff6c5f4a0]: LOADGROUP [b222be50]: Removing request b8d1d058 http://people.mozilla.org/~mwargers/tests/intermittent/394751.xhtml status 8000ffff (count=1). where 8000ffff means NS_ERROR_UNEXPECTED, which comes from the html parser with the attached stack. http://hg.mozilla.org/mozilla-central/annotate/675913ddbb55/parser/htmlparser/nsParser.cpp#l1844 The reason for mParserContext->mRequest == 0 here is this: http://hg.mozilla.org/mozilla-central/annotate/675913ddbb55/parser/htmlparser/nsParser.cpp#l912 If I comment out line 913 the test seems to work fine.
Flags: needinfo?(hsivonen)
I don't have anything intelligent to say. So sad that we still use nsParser to drive XML parsing. Maybe mrbkap has a better idea of how mParserContext is supposed to be relevant to XML.
Flags: needinfo?(hsivonen) → needinfo?(mrbkap)
I don't know exactly what's happening here, but I suspect that mParserContext->mRequest being null is a red herring. What's supposed to happen for an XML parser error (from the parser's end) is that we detect the error, end up returning NS_ERROR_HTMLPARSER_STOPPARSING from nsExpatDriver::ConsumeToken, which causes us to call nsParser::Terminate, which (I believe) is supposed to fire onload and any other load events. If that happens before the last packet comes from the network, that should be OK. Is there something I'm missing?
Flags: needinfo?(mrbkap)
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: