902239 - "System JS : ERROR file:///Users/cltbld/talos-slave/test/build/tests/reftest/tests/content/xbl/crashtests/232095-1.xul:15 SyntaxError: missing ) after argument list" in green reftest runs

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Ryan VanderMeulen [:RyanVM]]

Due to recent TBPL log parsing improvements in bug 892958, we're seeing more errors than we used to. Is the error below something we can/should fix, or should we simply blacklist it?

https://tbpl.mozilla.org/php/getParsedLog.php?id=26193338&full=1&branch=fx-team#error0

Rev4 MacOSX Lion 10.7 fx-team debug test crashtest on 2013-08-05 18:38:07 PDT for push c3c76cfca848

18:42:16     INFO -  REFTEST TEST-START | file:///Users/cltbld/talos-slave/test/build/tests/reftest/tests/content/xbl/crashtests/232095-1.xul
18:42:16     INFO -  REFTEST TEST-LOAD | file:///Users/cltbld/talos-slave/test/build/tests/reftest/tests/content/xbl/crashtests/232095-1.xul | 377 / 2507 (15%)
18:42:16     INFO -  ++DOMWINDOW == 79 (0x10a927368) [serial = 834] [outer = 0x10b2ea258]
18:42:16     INFO -  System JS : ERROR file:///Users/cltbld/talos-slave/test/build/tests/reftest/tests/content/xbl/crashtests/232095-1.xul:15
18:42:16     INFO -                       SyntaxError: missing ) after argument list
18:42:16     INFO -  WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../../content/xbl/src/nsXBLProtoImpl.cpp, line 57
18:42:16     INFO -  WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file ../../../../content/xbl/src/nsXBLService.cpp, line 513
18:42:16     INFO -  REFTEST TEST-PASS | file:///Users/cltbld/talos-slave/test/build/tests/reftest/tests/content/xbl/crashtests/232095-1.xul | (LOAD ONLY)

Comment 1

[Boris Zbarsky [:bzbarsky]]

The test is testing that having a syntax error in a binding doesn't cause crashes.

I suppose we could try installing an onerror handler that catches the error and causes it to not be reported, but it seems simpler (and more likely to not change what the test is testing) to blacklist if possible.

That said, we have a number of bugs that test things like error reporting; if the harness treats every uncaught JS exception as a problem, it'll hit a lot of problems... :(

Comment 2

[Ed Morley [:emorley]]

Blacklisting in TBPL is not really preferred as a long term solution - in addition, I believe exceptions like these (albeit not this specific case) should be turning the test run orange (it currently doesn't), which would mean needing to specify to the harness that this exception is expected, anyway.

Comment 3

[Boris Zbarsky [:bzbarsky]]

At the point at which this test harness starts turning orange on exceptions, it would presumably end up with a way to tell it the exception is expected...

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Ed, so the plan for this is to basically address it as a "known fail" once we turn these fatal?

Comment 5

[Ed Morley [:emorley]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #4)
> Ed, so the plan for this is to basically address it as a "known fail" once
> we turn these fatal?

I would guess so, yes :-)