Closed Bug 476871 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: gkw, Assigned: gal)

References

Details

(5 keywords, Whiteboard: [sg:critical?], fixed-in-tracemonkey)

Attachments

(3 files, 4 obsolete files)

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
Flags: wanted1.9.1?
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
Group: core-security
Flags: blocking1.9.1?
Keywords: crash
Whiteboard: [sg:critical?]
Is this a dupe of bug 476214 (or vice versa?)
See bug 476214 which looks to be similar/same.
Flags: wanted1.9.1?
Flags: blocking1.9.1?
Flags: blocking1.9.1+
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.
The first bad revision is:
changeset:   23907:186e782c623d
user:        David Anderson <danderson@mozilla.com>
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.
Depends on: 469044
Keywords: regression
Attached patch patch (obsolete) — Splinter Review
Assignee: general → gal
Status: NEW → ASSIGNED
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.
Attachment #365998 - Flags: review?(jorendorff)
Attached patch v2 (obsolete) — Splinter Review
Attachment #365998 - Attachment is obsolete: true
Attachment #366009 - Flags: review?(jorendorff)
Attachment #365998 - Flags: review?(jorendorff)
Attached patch v2, corrected (obsolete) — Splinter Review
Attachment #366009 - Attachment is obsolete: true
Attachment #366018 - Flags: review?(jorendorff)
Attachment #366009 - Flags: review?(jorendorff)
Attached patch v3 (obsolete) — Splinter Review
Attachment #366018 - Attachment is obsolete: true
Attachment #366028 - Flags: review?(jorendorff)
Attachment #366018 - Flags: review?(jorendorff)
Better but it has to be more paranoid, like

  if (!SPROP_HAS_STUB_SETTER(sprop))
      ABORT_TRACE("lulz");
Attached patch v4Splinter Review
Attachment #366028 - Attachment is obsolete: true
Attachment #366033 - Flags: review?(jorendorff)
Attachment #366028 - Flags: review?(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.
Attachment #366033 - Flags: review?(jorendorff) → review+
http://hg.mozilla.org/tracemonkey/rev/1852d9fe853d
Whiteboard: [sg:critical?] → [sg:critical?], fixed-in-tracemonkey
Depends on: 481989
This bug is a regression of (i.e. blocks) bug 469044, fixing wrong direction.
Blocks: 469044
No longer depends on: 469044
http://hg.mozilla.org/mozilla-central/rev/1852d9fe853d
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-testsuite+
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
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Group: core-security
Flags: wanted1.9.0.x-
test checked into 1.9.0, 1.9.1, 1.9.2, tracemonkey. 1.9.3 will get picked up in the next merge.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: