Bug 119395 - Crash in JSCell::methodTable under errorDescriptionForValue()
Summary: Crash in JSCell::methodTable under errorDescriptionForValue()
Status: RESOLVED DUPLICATE of bug 120080
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://www.sfgate.com
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-01 06:05 PDT by peavo
Modified: 2013-09-05 06:35 PDT (History)
5 users (show)

See Also:


Attachments
Patch (1.19 KB, patch)
2013-08-01 06:10 PDT, peavo
no flags Details | Formatted Diff | Diff
Patch (1.59 KB, patch)
2013-08-16 07:30 PDT, peavo
ggaren: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description peavo 2013-08-01 06:05:25 PDT
I'm getting a crash (NULL pointer access violation) in JavaScriptCore.

This is the stacktrace:

 	JavaScriptCore.dll!JSC::JSCell::methodTable()  Line 157	C++
	JavaScriptCore.dll!JSC::errorDescriptionForValue(JSC::ExecState * exec, JSC::JSValue v)  Line 112 + 0xe bytes	C++
 	JavaScriptCore.dll!JSC::createError(JSC::ExecState * exec, JSC::JSObject * (JSC::ExecState *, const WTF::String &)* errorFactory, JSC::JSValue value, const WTF::String & message)  Line 117 + 0x24 bytes	C++
 	JavaScriptCore.dll!JSC::createNotAnObjectError(JSC::ExecState * exec, JSC::JSValue value)  Line 141 + 0x28 bytes	C++
 	JavaScriptCore.dll!JSC::JSValue::synthesizePrototype(JSC::ExecState * exec)  Line 111 + 0xe bytes	C++
 	JavaScriptCore.dll!JSC::JSValue::get(JSC::ExecState * exec, unsigned int propertyName, JSC::PropertySlot & slot)  Line 660	C++
 	JavaScriptCore.dll!JSC::getByVal(JSC::ExecState * callFrame, JSC::JSValue baseValue, JSC::JSValue subscript, JSC::ReturnAddressPtr returnAddress)  Line 1542	C++
 	JavaScriptCore.dll!cti_op_get_by_val_generic(void * * args)  Line 1603	C++
 	0c192fce()	
 	JavaScriptCore.dll!JSC::JITCode::execute(JSC::JSStack * stack, JSC::ExecState * callFrame, JSC::VM * vm)  Line 46 + 0x20 bytes	C++
 	JavaScriptCore.dll!JSC::Interpreter::execute(JSC::ProgramExecutable * program, JSC::ExecState * callFrame, JSC::JSObject * thisObj)  Line 856 + 0x2d bytes	C++
 	JavaScriptCore.dll!JSC::evaluate(JSC::ExecState * exec, const JSC::SourceCode & source, JSC::JSValue thisValue, JSC::JSValue * returnedException)  Line 85	C++
 	WebKit.dll!WebCore::JSMainThreadExecState::evaluate(JSC::ExecState * exec, const JSC::SourceCode & source, JSC::JSValue thisValue, JSC::JSValue * exception)  Line 74 + 0x1b bytes	C++
 	WebKit.dll!WebCore::ScriptController::evaluateInWorld(const WebCore::ScriptSourceCode & sourceCode, WebCore::DOMWrapperWorld * world)  Line 142 + 0x34 bytes	C++
 	WebKit.dll!WebCore::ScriptController::evaluate(const WebCore::ScriptSourceCode & sourceCode)  Line 158 + 0x40 bytes	C++
 	WebKit.dll!WebCore::ScriptElement::executeScript(const WebCore::ScriptSourceCode & sourceCode)  Line 316 + 0x16 bytes	C++
 	WebKit.dll!WebCore::ScriptRunner::timerFired(WebCore::Timer<WebCore::ScriptRunner> * timer)  Line 121 + 0x2a5 bytes	C++
 	WebKit.dll!WebCore::Timer<WebCore::ProgressTracker>::fired()  Line 114 + 0xb bytes	C++
 	WebKit.dll!WebCore::ThreadTimers::sharedTimerFiredInternal()  Line 132	C++
 	WebKit.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd, unsigned int message, unsigned int wParam, long lParam)  Line 111	C++
Comment 1 peavo 2013-08-01 06:10:55 PDT
Created attachment 207921 [details]
Patch
Comment 2 Geoffrey Garen 2013-08-01 08:45:37 PDT
Comment on attachment 207921 [details]
Patch

Can you provide a test case for this?

I don't think checking isEmpty() here is right. Generally, JSValue() is not a valid value to use in the JIT or to pass to a runtime function. It's like a null pointer.
Comment 3 Mark Hahnenberg 2013-08-01 14:41:47 PDT
Can you give us steps to reproduce the issue? Then we can help you investigate!
Comment 4 peavo 2013-08-02 05:33:39 PDT
(In reply to comment #3)
> Can you give us steps to reproduce the issue? Then we can help you investigate!

I don't have a reduced testcase, but I'm consistently getting the crash on many sites, e.g. www.sfgate.com. I'm running on Windows (WinCairo) though, so I'm not sure you will see the same crash if you're on OSX.
Comment 5 peavo 2013-08-16 07:30:53 PDT
Created attachment 208924 [details]
Patch
Comment 6 peavo 2013-08-16 07:33:33 PDT
I'm frequently getting this crash. Trying another patch, but I assume it's not sufficient, as it doesn't address the root cause of the crash, but only avoids it :) I have not yet been able to figure out the origin of the empty JSValue.
Comment 7 Mark Hahnenberg 2013-08-16 08:06:55 PDT
(In reply to comment #6)
> I'm frequently getting this crash. Trying another patch, but I assume it's not sufficient, as it doesn't address the root cause of the crash, but only avoids it :) I have not yet been able to figure out the origin of the empty JSValue.

The original backtrace seems to indicate that you got the empty JSValue from inside the baseline JIT (cti_op_blah_blah_blah is a baseline JIT stub). Have you tried disabling the JITs to see if the issue goes away? You can do this by setting "useJIT() = false;" in Options::initialize in Options.cpp and recompiling. If that makes the problem go away then try just disabling the top tier JIT by setting "useDFGJIT() = false;" in the same manner (and removing "useJIT() = false;" where you added it previously). These experiments will tell us which execution engine (the LLInt, the baseline JIT, or the DFG JIT) is responsible for the empty JSValue you're seeing.

This all should take < 5 minutes to build both versions. How long does it usually take to see this crash when browsing around the web?
Comment 8 peavo 2013-08-16 11:51:29 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > I'm frequently getting this crash. Trying another patch, but I assume it's not sufficient, as it doesn't address the root cause of the crash, but only avoids it :) I have not yet been able to figure out the origin of the empty JSValue.
> 
> The original backtrace seems to indicate that you got the empty JSValue from inside the baseline JIT (cti_op_blah_blah_blah is a baseline JIT stub). Have you tried disabling the JITs to see if the issue goes away? You can do this by setting "useJIT() = false;" in Options::initialize in Options.cpp and recompiling. If that makes the problem go away then try just disabling the top tier JIT by setting "useDFGJIT() = false;" in the same manner (and removing "useJIT() = false;" where you added it previously). These experiments will tell us which execution engine (the LLInt, the baseline JIT, or the DFG JIT) is responsible for the empty JSValue you're seeing.
> 
> This all should take < 5 minutes to build both versions. How long does it usually take to see this crash when browsing around the web?

Thanks for the response!

I tried setting "useJIT() = false;", but I get the same crash. I believe both LLInt and the DFG JIT is disabled on Windows, so I guess there's no fallback, so baseline JIT is used regardless? I get the same stacktrace with cti_op_get_by_val_generic, which indicates this. Should I try to enable the DFG JIT? I usually see the crash quickly (within minutes or less) when browsing around. It happens every time when I visit www.sfgate.com.
Comment 9 Darin Adler 2013-08-16 12:07:07 PDT
Comment on attachment 208924 [details]
Patch

This seems wrong. It’s not correct to call this with an empty JSValue. Where is that happening?
Comment 10 peavo 2013-08-16 12:15:20 PDT
(In reply to comment #9)
> (From update of attachment 208924 [details])
> This seems wrong. It’s not correct to call this with an empty JSValue. Where is that happening?

I get it every time on www.sfgate.com (Windows).
Comment 11 Julien Brianceau 2013-08-27 15:18:59 PDT
Seems to be a duplicate of https://bugs.webkit.org/show_bug.cgi?id=120080
Comment 12 Geoffrey Garen 2013-08-27 16:47:54 PDT
Comment on attachment 208924 [details]
Patch

We really need to figure out why these values are NULL. They shouldn't be.
Comment 13 Julien Brianceau 2013-08-28 02:30:06 PDT
(In reply to comment #10)
> I get it every time on www.sfgate.com (Windows).

Could you test the patch I've just submitted in https://bugs.webkit.org/show_bug.cgi?id=120080 and give your feedback with your Windows build please?
Comment 14 peavo 2013-09-05 06:35:26 PDT
Thanks alot, that patch did the trick :)

*** This bug has been marked as a duplicate of bug 120080 ***