Closed Bug 483179 Opened 15 years ago Closed 15 years ago

TM: JIT embeds stale closure in trace for JSOP_DEFLOCALFUN

Categories

(Core :: JavaScript Engine, defect, P1)

1.9.1 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: s.a.moeller, Unassigned)

References

Details

(Keywords: regression, testcase, verified1.9.1, Whiteboard: fixed-in-tracemonkey)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b4pre) Gecko/20090313 SeaMonkey/2.0b1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b4pre) Gecko/20090313 SeaMonkey/2.0b1pre

If you assign the value of "this" to a JavaScript object's private variable, and then read that variable's value, it is - under certain circumstances - referring to *another* object of the same class.

Reproducible: Always

Steps to Reproduce:
See attached testcase. The testcase contains a loop over 20 individual instances of the same class.
Actual Results:  
The values of "this.id" and "thisObject.id" should be identical for all the individual objects.

Expected Results:  
In some of the objects those values are different.

This bug happens in SeaMonkey 2.0 only. Neither Seamonkey 1.x nor Firefox 3.0 show this behaviour.
Attached file testcase
Keywords: regression
Can you also check with Firefox 3.1b3 which corresponds to SeaMonkey 2.0a3
Assignee: nobody → general
Component: General → JavaScript Engine
Product: SeaMonkey → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch
Beward: the "testcase" attachment puts up 20 alerts.

/be
This is a blocker for sure - thanks for filing it!

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Assignee: general → jorendorff
"thisObject" gets the wrong answer. "this" is correct.

I think the JIT is not emitting the right guards for this kind of property cache hit.
Summary: JavaScript variable "this" is referring to the wrong object → TM: JIT emits code for JSOP_NAME (in closure) that looks in the wrong scope
Correction, the JIT correctly bails out of the second loop.  The problem is in the first loop, the one that creates the closures.  We can't create closures on trace yet, not until upvar2 lands.  We shouldn't be recording JSOP_DEFLOCALFUN.
I misspoke on IRC: the upvar2 patch does fix this bug.

/be
Depends on: upvar2
(In reply to comment #5)
> "thisObject" gets the wrong answer. "this" is correct.
> 
> I think the JIT is not emitting the right guards for this kind of property
> cache hit.

Those poor guards, when will they earn your respect? When, I ask! :-P

/be
Attachment #367306 - Flags: review?(brendan)
Comment on attachment 367306 [details] [diff] [review]
v1 (although upvar2 obsoletes this)

Before b3, sure. With upvar2 close, would rather avoid the conflict and charge hard across the goal line.

/be
Summary: TM: JIT emits code for JSOP_NAME (in closure) that looks in the wrong scope → TM: JIT embeds stale closure in trace for JSOP_DEFLOCALFUN
Priority: -- → P1
Un-taking.
Assignee: jorendorff → general
Comment on attachment 367306 [details] [diff] [review]
v1 (although upvar2 obsoletes this)

I think we should take this, it seems like it'd be possible to fool upvar2 with a |with| statement or |eval|, leading back to this bug.
Attachment #367306 - Flags: review+
http://hg.mozilla.org/tracemonkey/rev/25220accae01
Whiteboard: fixed-in-tracemonkey
http://hg.mozilla.org/mozilla-central/rev/25220accae01
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
verified FIXED on builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090422 Shiretoko/3.5b4pre ID:20090422042031
Status: RESOLVED → VERIFIED
Keywords: testcase
OS: Windows 2000 → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: