[webkit-dev] Odd behavior with instrumentation of WebKit

[Gregor Richards]

On 03/15/11 18:31, Darin Adler wrote:
> On Mar 15, 2011, at 8:16 AM, Gregor Richards wrote:
>
>   
>> We maintain an instrumented branch of WebKit to do various dynamic
>> measurements of JavaScript. One of our changes which should have no
>> semantic effect on the behavior of JS is actually causing a visible
>> change in the behavior of (at least) http://about.com/ . The visible
>> difference is that the menus don't work, and the underlying reason
>> seems to be that Array.prototype.slice is (rather inexplicably) being
>> rewritten to undefined, causing further code to fail. I've worked the
>> issue down to a single line, namely
>>
>>
>>
>> baseValue.toObject(callFrame)->hasOwnProperty(callFrame, property);
>>
>>
>>
>> A patch is attached giving context. This is under a
>> baseValue.isObject() check, and this is simply a hasOwnProperty check
>> (not getting the value, which could call a getter, or even using
>> prototypes), so to my knowledge this should not effect the behavior of
>> the program in any way. This line is of course useless on its own, it's
>> just the culprit expression I've extracted from the rest of the
>> instrumentation.
>>
>>
>>
>> Is there a WebKit guru who can enlighten us on this odd behavior?
>>
>>
>>
>> The patch is against WebKit r80431, but the behavior is the same on
>> older versions. I haven't tried newer versions simply because our
>> branch is synchronized on a weekly basis, but I don't expect that
>> anything relevant has changed this week.
> It’s good that you reduced your JavaScript changes down to a single line. Next step would be to make a local copy of the about.com site, reproduce the bug with that, and then reduce it as well. Once you do that it you can get to the bottom of it quickly.
>
>     -- Darin
>
>   


After a lot of effort, we reduced the JavaScript as well. The resulting
JS doesn't reproduce precisely the behavior we described, but it does
show a difference: In the uninstrumented branch (both JIT and
interpreter), the lastIndexOf property of Array.prototype (which we set)
is marked as enumerable, so a for...in loop outputs it. In the branch
with our small three-line change (two to the interpreter, one to disable
the JIT), in which all we do is check for the existence of this property
before overwriting it, the lastIndexOf property is marked as
unenumerable, so the following for...in loop does NOT output it. I
believe the correct, spec'd behavior is for both versions to be
unenumerable.

I've attached the patch (against WebKit r76456 in this case, see older
mail for original patch) and the HTML with embedded JavaScript to
reproduce the difference. The patch is small and should work against
later versions, I am yet to find a version that does not produce the
same difference.

So, to ask again: is there a WebKit guru who can enlighten us on this
odd behavior? This seems to be a bug in the implementation of
hasOwnProperty, but it could be that using that function just brings
about a bug elsewhere. Ultimately this caused certain web pages
(including an old version of about.com) to behave differently with our
instrumentation, so we'd like to fix anything that's wrong.

 - Gregor Richards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110517/4c1c8689/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: webkit-r76456-hasownproperty-bug.diff
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110517/4c1c8689/attachment.ksh>