476871 - TM: "Assertion failure: *(JSObject**)slot == NULL, at ../jstracer.cpp" with watch

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

let ([] = false) { (this.watch("x", /a/g)); };
(function () { (eval("(function(){for each (x in [1, 2, 2]);});"))(); })();

asserts debug TM at Assertion failure: *(JSObject**)slot == NULL, at ../jstracer.cpp:1587 but seems to work as expected in TM opt. TM-only.

===
/snip
--------------------------------------- end exit block 0x257384

    0x258ff8  [epilogue]                     
              mov esp,ebp                    
              pop ebp                        
              pop ebp                        
              pop ebx                        
              pop esi                        
              pop edi                        
              ret                            
fragment 0x257004:
ENTRY: S0 S5 S0 S1 G5 
EXIT:  S0 S5 S0 S2 G5 
recording completed at typein:2@14 via closeLoop
Looking for compat peer 2@14, from 0x257004 (ip: 0x30cf5a, hits=2)
checking vm types 0x257004 (ip: 0x30cf5a): callee0=O/O this0=O/N stack0=O/O stack1=I/I global0=O/N 
entering trace at typein:2@14, native stack slots: 6 code: 0x258f30
global: 
stack: callee0=object<0x29a8f8:Function> this0=stack0=object<0x294280:Iterator> stack1=int<2> 
leaving trace at typein:2@17, op=nextiter, lr=0x2572dc, exitType=3, sp=2, calldepth=0, cycles=83105
Assertion failure: *(JSObject**)slot == NULL, at ../jstracer.cpp:1587
Trace/BPT trap

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

this.watch("NaN", /a/g)
let(x) 
((function(){
    for each (NaN in [null, '', '', '', '']) true;
}
)());
NaN.( /x/ )


is a testcase that I've seen produce these asserts during reduction, also crashing at opt TM at 0x20000004 at js_StepXMLListFilter. The testcase here now has changed to also crash at debug TM at the same locations. Filing under the same bug because they seem similar and both involve TM and watch. Security-locking and nominating blocking1.9.1 because of possibly exploitable testcase.

The testcase in comment #0 still has the same symptoms.


verbose output from latest testcase:

/snip
--------------------------------------- end exit block 0x2625ac

    0x263f56  [epilogue]                     
              mov esp,ebp                    
              pop ebp                        
              pop ebp                        
              pop ebx                        
              pop esi                        
              pop edi                        
              ret                            
patching jump at 0x2adffb to target 0x263ec3 (was 0x263ff8)

Joining type-stable trace to target exit 0x30f600->0x262294.
fragment 0x30f600:
ENTRY: S0 S5 S0 S4 G0 
fragment 0x3105f0:
ENTRY: S0 S5 S0 S4 G5 
recording completed at typein:4@22 via closeLoop
Looking for compat peer 4@22, from 0x30f600 (ip: 0x30ec36, hits=3)
checking vm types 0x30f600 (ip: 0x30ec36): callee0=O/O this0=O/N stack0=O/O stack1=S/S global0=O/O 
entering trace at typein:4@22, native stack slots: 6 code: 0x263f5e
global: object<0x29f4e0:Array> 
stack: callee0=object<0x29f400:Function> this0=stack0=object<0x29f4a0:Iterator> stack1=string<0x2a1000> 
leaving trace at typein:4@25, op=nextiter, lr=0x262500, exitType=5, sp=2, calldepth=0, cycles=47839
object<0x2a1000:(null)> 
callee0=object<0x29f400:Function> this0=null<0x0> stack0=object<0x29f4a0:Iterator> stack1=box<1e> 
Flushing fragments for JSScript 0x30ec50.
js> NaN.( /x/ )
Segmentation fault

Comment 2

[Daniel Veditz [:dveditz]]

Is this a dupe of bug 476214 (or vice versa?)

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

See bug 476214 which looks to be similar/same.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This bug is weird because bug 466654 was first discovered to have another symptom, which morphed to this assertion over time. bug 469254 refers to this assertion, but as the first one morphed, was duped to that bug. (Both were found via fuzzers.) This is commented in https://bugzilla.mozilla.org/show_bug.cgi?id=476214#c1 Both were eventually found to be WFM on TM tip.

bug 476214 is a real world manifestation that came in not long later, and I suspect whether they are related to landings of TM on m-c trunk that did not WFM on TM tip. It also doesn't seem to crash on opt.

This bug keeps reappearing and comment #0 shows a non-exploitable assertion, but comment #1 is a possibly exploitable one. To prevent another morph of the bug (and more jumping over to real world scenarios, especially since a possible exploit is found), this bug should be looked at asap.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The first bad revision is:
changeset:   23907:186e782c623d
user:        David Anderson <[e-mail]>
date:        Thu Jan 22 01:45:19 2009 -0500
summary:     Specialize trees to global types, so global type instability does not flush the cache (bug 469044, r=gal,brendan).

This regression confirmed via hg bisect to be due to the changeset above, for both testcases in comments 0 and 1.

Comment 6

[Andreas Gal :gal]

Attachment: patch

Comment 7

[Andreas Gal :gal]

Gary, could you please retest all current fuzzer bugs that use "watch". I think the patch will fix those as well and you can dup them against this bug here.

Comment 8

[Andreas Gal :gal]

Attachment: v2

Comment 9

[Andreas Gal :gal]

Attachment: v2, corrected

Comment 10

[Andreas Gal :gal]

Attachment: v3

Comment 11

[Jason Orendorff [:jorendorff]]

Better but it has to be more paranoid, like

  if (!SPROP_HAS_STUB_SETTER(sprop))
      ABORT_TRACE("lulz");

Comment 12

[Andreas Gal :gal]

Attachment: v4

Comment 13

[Jason Orendorff [:jorendorff]]

Comment on attachment 366033 [details] [diff] [review]
v4

> +    JS_ASSERT(!(sprop->attrs & JSPROP_READONLY));
> +    JS_ASSERT(!(sprop->attrs & JSPROP_READONLY));

Looks just right, but lose the doubled assertion.

Comment 15

[Andreas Gal :gal]

http://hg.mozilla.org/tracemonkey/rev/1852d9fe853d

Comment 16

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

This bug is a regression of (i.e. blocks) bug 469044, fixing wrong direction.

Comment 17

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/1852d9fe853d

Comment 18

[Bob Clary [:bc] (inactive)]

Attachment: js1_8/extensions/regress-476871-01.js

Comment 19

[Bob Clary [:bc] (inactive)]

Attachment: js1_8/extensions/regress-476871-02.js

Comment 20

[Bob Clary [:bc] (inactive)]

http://hg.mozilla.org/tracemonkey/rev/3fb1b5d6dc60
/cvsroot/mozilla/js/tests/js1_8_1/trace/trace-test.js,v  <--  trace-test.js
new revision: 1.13; previous revision: 1.12

Comment 21

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d7af6c8477b4

Comment 22

[Bob Clary [:bc] (inactive)]

v 1.9.1, 1.9.2

Comment 23

[Bob Clary [:bc] (inactive)]

test checked into 1.9.0, 1.9.1, 1.9.2, tracemonkey. 1.9.3 will get picked up in the next merge.