Bug 20633 – Crash in privateExecute @ cs.byu.edu

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[BJ Homer]

Visiting http://cs.byu.edu/courses/current with the latest nightly build crashes the entire browser.  Error log points to a JavaScript error.

[Mark Rowe (bdash)]

Can you please attach a crash log?  See <http://webkit.org/quality/crashlogs.html> for details about how to get a crash log.

[Mark Rowe (bdash)]

<rdar://problem/6194259>

[Matt Lilek]

ASSERTION FAILED: protoObject->get(exec, codeBlock->identifiers[vPC[3].u.operand]) == protoObject->getDirectOffset(offset)
(/Users/matt/Code/WebKit/JavaScriptCore/VM/Machine.cpp:2236 KJS::JSValue* KJS::Machine::privateExecute(KJS::Machine::ExecutionFlag, KJS::ExecState*, KJS::RegisterFile*, KJS::Register*, KJS::ScopeChainNode*, KJS::CodeBlock*, KJS::JSValue**))

Thread 0 Crashed:
0   com.apple.JavaScriptCore      	0x0050ceea KJS::Machine::privateExecute(KJS::Machine::ExecutionFlag, KJS::ExecState*, KJS::RegisterFile*, KJS::Register*, KJS::ScopeChainNode*, KJS::CodeBlock*, KJS::JSValue**) + 25932 (Machine.cpp:2236)
1   com.apple.JavaScriptCore      	0x005118a6 KJS::Machine::execute(KJS::ProgramNode*, KJS::ExecState*, KJS::ScopeChainNode*, KJS::JSObject*, KJS::JSValue**) + 698 (Machine.cpp:795)
2   com.apple.JavaScriptCore      	0x004a380f KJS::Interpreter::evaluate(KJS::ExecState*, KJS::ScopeChain&, KJS::UString const&, int, WTF::PassRefPtr<KJS::SourceProvider>, KJS::JSValue*) + 427 (interpreter.cpp:83)
3   com.apple.WebCore             	0x038f1766 WebCore::ScriptController::evaluate(WebCore::String const&, int, WebCore::String const&) + 268 (ScriptController.cpp:116)
4   com.apple.WebCore             	0x0347cc83 WebCore::FrameLoader::executeScript(WebCore::String const&, int, WebCore::String const&) + 153 (FrameLoader.cpp:790)
5   com.apple.WebCore             	0x0350e9a2 WebCore::HTMLTokenizer::scriptExecution(WebCore::String const&, WebCore::HTMLTokenizer::State, WebCore::String const&, int) + 300 (HTMLTokenizer.cpp:559)
6   com.apple.WebCore             	0x035100b3 WebCore::HTMLTokenizer::scriptHandler(WebCore::HTMLTokenizer::State) + 1537 (HTMLTokenizer.cpp:498)
7   com.apple.WebCore             	0x0351070e WebCore::HTMLTokenizer::parseSpecial(WebCore::SegmentedString&, WebCore::HTMLTokenizer::State) + 996 (HTMLTokenizer.cpp:344)
8   com.apple.WebCore             	0x03512798 WebCore::HTMLTokenizer::parseTag(WebCore::SegmentedString&, WebCore::HTMLTokenizer::State) + 6778 (HTMLTokenizer.cpp:1512)
9   com.apple.WebCore             	0x03513145 WebCore::HTMLTokenizer::write(WebCore::SegmentedString const&, bool) + 1521 (HTMLTokenizer.cpp:1747)
10  com.apple.WebCore             	0x0350eebf WebCore::HTMLTokenizer::notifyFinished(WebCore::CachedResource*) + 807 (HTMLTokenizer.cpp:2027)

[Mark Rowe (bdash)]

The assertion failure looks sorta similar to that on bug 20626.

[Cameron Zwarich (cpst)]

I'll assign this to myself, since I can't work on bug 20626.

[Cameron Zwarich (cpst)]

Created attachment 23154 [details]
Partial reduction

Here is a reduction of the bug. It loads 3 JS libraries and runs one command. Now it's time to pick apart the libraries.

[Matt Lilek]

*** Bug 20636 has been marked as a duplicate of this bug. ***

[Cameron Zwarich (cpst)]

Created attachment 23156 [details]
Further reduction

I can't seem to reduce it much further than this. This bug is very sensitive to the number of properties added to objects, even if they are never actually used. I have been able to replace some useless functions with blank bodies, but removing useless code from the bodies of functions that are actually called can cause the problem to go away.

[Cameron Zwarich (cpst)]

Created attachment 23157 [details]
CodeBlock dump

Here is a CodeBlock dump of the crash. The crash occurs at instruction 216, which is the lookup of setArray in the jQuery constructor. The actual property seems to be the right value, but the fast offset lookup returns 0.

[Cameron Zwarich (cpst)]

This is a strange crash. When the lookup is optimized to become get_by_id_proto, the slot holds the correct value. However, it is zero'd out some time before the lookup is made. I'll try to figure out what is clearing it. There is nothing in the JS code that is supposed to write to it, at least as far as I can tell.

[Matt Lilek]

*** Bug 20637 has been marked as a duplicate of this bug. ***

[Cameron Zwarich (cpst)]

The problem occurs in PropertyMap::rehash(). After the only rehash of a PropertyMap table with newTableSize 512, the value with offset 281 is zeroed out. Before the rehash, it is the correct value.

[Geoffrey Garen]

Committed revision 36081.

[Cameron Zwarich (cpst)]

*** Bug 20640 has been marked as a duplicate of this bug. ***

[Kevin Broderick]

Confirming that errant behavior as exhibited on Sears site is no longer present in current nightly (4 Sep 08).

[Grant]

Fixed, many thanks.