[Webkit-unassigned] [Bug 33450] New: property access (. operator) incorrectly returning prototype value not instance value

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33450

           Summary: property access (. operator) incorrectly returning
                    prototype value not instance value
           Product: WebKit
           Version: 312.x
          Platform: Macintosh Intel
        OS/Version: Mac OS X 10.6
            Status: UNCONFIRMED
          Severity: Critical
          Priority: P1
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ptw at pobox.com


Created an attachment (id=46233)
 --> (https://bugs.webkit.org/attachment.cgi?id=46233)
.zip file of application demonstrating bug in Safari Version 4.0.4 (6531.21.10)

We have a large/complex Javascript system that appears to be triggering a
(possibly storage or timing-dependent) error in the Javascript engine.  The
symptoms are that an object property is being accessed using the `.` operator
and the value being returned is _not_ the value in the object, but instead the
value in the object's __proto__.  If we replace the failing case by rewriting
`x.prop` to `x['prop']`, the code works as expected.  We have not been able to
create a small test case that exhibits this error.  We do see this error appear
in a number of applications generated by our system, but the error is not
always in the same location, and a test case that is failing in the current
Safari release Version 4.0.4 (6531.21.10), may not fail in the Webkit Nightly
build.

I have attached the smallest example that I can make as a .zip file.  If you
unpack the .zip file and open the .html within, it will halt on a null
dereference in the current Safari release.  It works correctly in Firefox.

The erroneous evaluation occurs in the file lps/includes/lfc/LFCdhtml.js on
line 667.  If the expression `$2.defaultplacement` is rewritten as
`$2['defaultplacement']`, then the application behaves correctly.

This same test application does _not_ fail in the current Webkit nightly
r52978, but we still see failures of a similar nature with other programs in
the nightly build, so I do not believe that this bug has been fixed, just that
it is an intermittent bug that is triggered by particular storage or timing
patterns.  I can try to create an additional test that demonstrates the failure
on the nightly build if that will help.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.