Last Comment Bug 690608 - Assertion failure: !assm->error() regression during Mochitest "test_webgl_conformance_test_suite.html"
: Assertion failure: !assm->error() regression during Mochitest "test_webgl_con...
: assertion, regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on: 693815
Blocks: 514067
  Show dependency treegraph
Reported: 2011-09-29 16:51 PDT by Doug Sherk (:drs) (inactive)
Modified: 2011-10-20 15:24 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

backtrace (2.33 KB, text/plain)
2011-10-11 15:21 PDT, Daniel Holbert [:dholbert]
no flags Details

Description Doug Sherk (:drs) (inactive) 2011-09-29 16:51:36 PDT
Steps to repro:

1) Build from mozilla-central
2) Run the following from obj on Linux (and possibly other platforms, haven't checked):
TEST_PATH=content/canvas/test/webgl make mochitest-plain

I don't think this happens on the TBPL builds, but I've found locally that when I run the WebGL Mochitests, around the 3rd test the entire thing will die with the following console output:

WebGL mochitest: starting page conformance/array-unit-tests.html
++DOMWINDOW == 18 (0x2aeb0383b878) [serial = 18] [outer = 0x2aeb03fdc400]
++DOMWINDOW == 19 (0x2aaaab90bc78) [serial = 19] [outer = 0x2aeb03fdc400]
Assertion failure: !assm->error(), at /home/dsherk/builds/mozilla-central4/js/src/jstracer.cpp:4666
TEST-UNEXPECTED-FAIL | | Exited with code -6 during test run
INFO | | Application ran for: 0:00:09.461703
INFO | | Reading PID log: /tmp/tmpt0yzG5pidlog

== BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, default process 32465

                                              Per-Inst   Leaked    Total      Rem      Mean       StdDev     Total      Rem      Mean       StdDev
   0 TOTAL                                          44        0       10        0 (    1.20 +/-     0.70)       16        0 (    1.56 +/-     0.84)

nsTraceRefcntImpl::DumpStatistics: 2 entries
TEST-PASS | automationutils.processLeakLog() | no leaks detected!

INFO | | Running tests: end.
make: *** [mochitest-plain] Error 250
Comment 1 Daniel Holbert [:dholbert] 2011-09-29 17:02:49 PDT
Doug says this test worked for him in a build from ~3 weeks ago, so this seems to have regressed sometime in the last 3 weeks.
Comment 2 Daniel Holbert [:dholbert] 2011-09-29 18:00:02 PDT
With some targeted builds, I've narrowed this (slightly) to this 10-day range:
Comment 3 Daniel Holbert [:dholbert] 2011-09-29 18:00:16 PDT
er 13-day
Comment 4 Daniel Holbert [:dholbert] 2011-09-30 00:21:15 PDT
Narrowed further:
Comment 5 Daniel Holbert [:dholbert] 2011-09-30 08:57:56 PDT
The first affected revision is:
e7525561c309	Josh Matthews — Bug 681392 - Remove about: exclusion from SpecialPowers creation. r=ted

I confirmed that a targeted backout of that cset will fix this in an up-to-date build, too.

That's a tweak to specialpowers.js (which is used in mochitests). It just exposed the bug; it's of course not the underlying JS-engine cause of the bug.
Comment 6 Daniel Holbert [:dholbert] 2011-09-30 15:53:47 PDT
This isn't a recent regression in the JS engine, FWIW -- I was able to reproduce it in a build from July, based off of this cset:
with the specialpowers.js cset from comment 5 applied manually.
Comment 7 David Mandelin [:dmandelin] 2011-10-11 14:20:07 PDT
This doesn't repro on Windows, and it doesn't repro on Linux in a debugger. The assertion is pretty much a can't-happen (it asserts !assm->error() very soon after guarding on assm->error()). These facts together make me suspect some kind of memory corruption from WebGL. But if not, it's a tracejit bug, and we plan on disabling the tracejit soon. So I'm not sure any action is required here.
Comment 8 Daniel Holbert [:dholbert] 2011-10-11 15:14:46 PDT
(In reply to David Mandelin from comment #7)
> and it doesn't repro on Linux in a debugger.

Repros just fine for me in a debugger.  I've got it caught in a debugger right now, if you'd like to take a look at all.
Comment 9 Daniel Holbert [:dholbert] 2011-10-11 15:21:34 PDT
Created attachment 566370 [details]

Here's the backtrace from GDB, when I hit the assertion-failure/abort.
Comment 10 Daniel Holbert [:dholbert] 2011-10-11 15:26:01 PDT
(In reply to David Mandelin from comment #7)
> But if not, it's a tracejit bug,
> and we plan on disabling the tracejit soon. So I'm not sure any action is
> required here.

(ah, ok.  I'm happy to let you investigate it in a debugger on my machine at some point if you like.  Otherwise, it sounds like it's not a big deal, if tracejit is being disabled soon.)
Comment 11 Daniel Holbert [:dholbert] 2011-10-11 15:35:34 PDT
FWIW, the assertion is:
>    Assembler *assm = traceMonitor->assembler;
>    JS_ASSERT(!assm->error());

When this fails, the value of assm->error() is "nanojit::BranchTooFar"
Comment 12 David Mandelin [:dmandelin] 2011-10-11 19:16:47 PDT
Thanks to Dan we figured out what this is. It's almost certainly a tracer bug where some paths that exit on assm->error() don't clear the error. So, it doesn't seem to be a WebGL bug. And the assertion is harmless. And it will go away when the tracer is pref'd off by default, which is tonight.
Comment 13 Bjarne (:bjarne) 2011-10-12 14:37:40 PDT
Fwiw: I see this with a fresh pull from mc (includes fix for bug #693815) in an xpcshell-test on 64-bit Linux. The exact output is

Assertion failure: !assm->error(), at /home/bjarne/Work/Mozilla/Trunk/mozilla-central/js/src/jstracer.cpp:4666

The test is part of a large, unfinished benchmark for the http-cache. I can email it directly if someone wants to reproduce...
Comment 14 Bjarne (:bjarne) 2011-10-17 07:30:57 PDT
Fwiw (again), I still see this on a clobber-build on m-c freshly updated today.
Comment 15 Daniel Holbert [:dholbert] 2011-10-17 14:49:45 PDT
Me too (in webgl mochitests, using the command from comment 0). Apparently jstracer isn't disabled after all, even though bug 693815 has been resolved for nearly a week?
Comment 16 Bjarne (:bjarne) 2011-10-20 15:01:55 PDT
My particular issue seems to be fixed now.
Comment 17 Daniel Holbert [:dholbert] 2011-10-20 15:24:33 PDT
makes sense; a more thorough fix for bug 693815 (disabling the tracer) landed on m-c early this morning.

Resolving as FIXED by that bug.

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