[Webkit-unassigned] [Bug 95073] WindowShell and global registers break IC

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 27 20:59:37 PDT 2012


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





--- Comment #6 from Yusuke Suzuki <utatane.tea at gmail.com>  2012-08-27 20:59:40 PST ---
(In reply to comment #5)
> Our typical defense against this type of bug is that the function doing the lookup and caching checks that the property owner (PropertySlot::slotBase()) is equal to the object on which it's doing the lookup, and refuses to cache if not. 
> 
> Do you know what goes wrong with that defense in this case?

Yes. forceUncacheable is necessary for browser environment, not JSC shell.

In the shell, global object is JSGlobalObject, but in the browser, global object is JSDOMWindowShell object(this is proxy to JSGlobalObject)
WindowShell object has JSGlobalObject and lookup operations are passed to JSGlobalObject. But this makes a severe problem.
https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSDOMWindowShell.h#L80

For example, we define own property to global and lookup.
window.a = 20;
window.a;

When lookup is executed, WindowShell lookups from JSGlobalObject.
https://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSDOMWindowShell.cpp#L94

As the result, when lookup is succceeded, slot.baseValue() is JSGlobalObject (not WindowShell).
But, `window` object(baseCell) is WindowShell. So currently JSC on Safari has already failed at self IC creation point.
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/jit/JITStubs.cpp#L932

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



More information about the webkit-unassigned mailing list