Bug 24596 – ASSERT in JSC::PropertySlot::slotBase @ iGoogle homepage

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Xan Lopez]

Happens every time I try to open the iGoogle homepage, with r41703, JIT enabled, x86:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb3f39a20 (LWP 25728)]
0xb67999fa in JSC::PropertySlot::slotBase (this=0xbf87875c) at ../../JavaScriptCore/runtime/PropertySlot.h:166
166	            ASSERT(m_slotBase);
Current language:  auto; currently c++
(gdb) bt
#0  0xb67999fa in JSC::PropertySlot::slotBase (this=0xbf87875c) at ../../JavaScriptCore/runtime/PropertySlot.h:166
#1  0xb6f0dc28 in JSC::JITStubs::tryCacheGetByID (callFrame=0xb27e6918, codeBlock=0x1027f2e8, returnAddress=0xad8fca74, baseValue=
      {m_ptr = 0xae281560}, propertyName=@0xff3002c, slot=@0xbf87875c) at ../../JavaScriptCore/jit/JITStubs.cpp:181
#2  0xb6f0dfe9 in JSC::JITStubs::cti_op_get_by_id_second (args=0xb0c5b000) at ../../JavaScriptCore/jit/JITStubs.cpp:549
#3  0xb6f041d1 in doubleHash (key=3213330472) at ../../JavaScriptCore/wtf/HashTable.h:437
#4  0xb6f973a6 in JSC::JITCode::execute (this=0xbf878844, registerFile=0x9551590, callFrame=0xb27e6918, globalData=0x954fa68, exception=0x954ff88)
    at ../../JavaScriptCore/jit/JITCode.h:86
#5  0xb6f81d03 in JSC::Interpreter::execute (this=0x9551588, functionBodyNode=0xffb9e38, callFrame=0xb27e67e0, function=0xb1cb09e0, 
    thisObj=0xb0e3db20, args=@0xbf878930, scopeChain=0xfea0378, exception=0x954ff88) at ../../JavaScriptCore/interpreter/Interpreter.cpp:689
#6  0xb6f2c6b0 in JSC::JSFunction::call (this=0xb1cb09e0, exec=0xb27e67e0, thisValue={m_ptr = 0xb0e3db20}, args=@0xbf878930)
    at ../../JavaScriptCore/runtime/JSFunction.cpp:82
#7  0xb6f44e5d in JSC::call (exec=0xb27e67e0, functionObject={m_ptr = 0xb1cb09e0}, callType=JSC::CallTypeJS, callData=@0xbf87898c, thisValue=
      {m_ptr = 0xb0e3db20}, args=@0xbf878930) at ../../JavaScriptCore/runtime/CallData.cpp:39
#8  0xb6f2f785 in functionProtoFuncApply (exec=0xb27e67e0, thisValue={m_ptr = 0xb1cb09e0}, args=@0xbf8789ec)
    at ../../JavaScriptCore/runtime/FunctionPrototype.cpp:125
#9  0xb6f0bb3e in JSC::JITStubs::cti_op_call_NotJSFunction (args=0x0) at ../../JavaScriptCore/jit/JITStubs.cpp:943
#10 0xb6f041d1 in doubleHash (key=3213331256) at ../../JavaScriptCore/wtf/HashTable.h:437
#11 0xb6f973a6 in JSC::JITCode::execute (this=0xbf878b64, registerFile=0x9551590, callFrame=0xb27e61d0, globalData=0x954fa68, exception=0xbf878c84)
    at ../../JavaScriptCore/jit/JITCode.h:86
#12 0xb6f81821 in JSC::Interpreter::execute (this=0x9551588, evalNode=0xff24510, callFrame=0xb27e6160, thisObj=0xb0c4ae80, 
    globalRegisterOffset=58, scopeChain=0xf8f9f40, exception=0xbf878c84) at ../../JavaScriptCore/interpreter/Interpreter.cpp:781
#13 0xb6f827e1 in JSC::Interpreter::callEval (this=0x9551588, callFrame=0xb27e6160, registerFile=0x9551590, argv=0xb27e6180, argc=2, 
    registerOffset=14, exceptionValue=@0xbf878c84) at ../../JavaScriptCore/interpreter/Interpreter.cpp:343
#14 0xb6f068c8 in JSC::JITStubs::cti_op_call_eval (args=0x0) at ../../JavaScriptCore/jit/JITStubs.cpp:1801
#15 0xb6f041d1 in doubleHash (key=3213331784) at ../../JavaScriptCore/wtf/HashTable.h:437
#16 0xb6f973a6 in JSC::JITCode::execute (this=0xbf878d5c, registerFile=0x9551590, callFrame=0xb27e6048, globalData=0x954fa68, exception=0xbf878ddc)
    at ../../JavaScriptCore/jit/JITCode.h:86
#17 0xb6f820c3 in JSC::Interpreter::execute (this=0x9551588, programNode=0x101087a8, callFrame=0xfd11db4, scopeChain=0xfdcf948, 
    thisObj=0xb0c4ae80, exception=0xbf878ddc) at ../../JavaScriptCore/interpreter/Interpreter.cpp:623
#18 0xb6fa3d11 in JSC::evaluate (exec=0xfd11db4, scopeChain=@0xfd11d70, source=@0xbf878ebc, thisValue={m_ptr = 0xb0c4ae80})
    at ../../JavaScriptCore/runtime/Completion.cpp:67
#19 0xb67f2305 in WebCore::ScriptController::evaluate (this=0xfe1216c, sourceCode=@0xbf878ebc)
    at ../../WebCore/bindings/js/ScriptController.cpp:112
#20 0xb694ee8b in WebCore::ScriptElementData::evaluateScript (this=0xfede540, sourceCode=@0xbf878ebc) at ../../WebCore/dom/ScriptElement.cpp:180
#21 0xb694ef76 in WebCore::ScriptElementData::notifyFinished (this=0xfede540, o=0xfee06a0) at ../../WebCore/dom/ScriptElement.cpp:205
#22 0xb6a9bfa8 in WebCore::CachedScript::checkNotify (this=0xfee06a0) at ../../WebCore/loader/CachedScript.cpp:106
#23 0xb6a9c08e in WebCore::CachedScript::data (this=0xfee06a0, data={m_ptr = 0xbf878fa8}, allDataReceived=true)
#24 0xb6aeef51 in WebCore::Loader::Host::didFinishLoading (this=0xfe75cd0, loader=0xfede8a0) at ../../WebCore/loader/loader.cpp:303
#25 0xb6ade597 in WebCore::SubresourceLoader::didFinishLoading (this=0xfede8a0) at ../../WebCore/loader/SubresourceLoader.cpp:183
#26 0xb6adc144 in WebCore::ResourceLoader::didFinishLoading (this=0xfede8a0) at ../../WebCore/loader/ResourceLoader.cpp:416
#27 0xb6d01b51 in finishedCallback (session=0x8c4d678, msg=0xf5ad2c0, data=0xfedda30)
    at ../../WebCore/platform/network/soup/ResourceHandleSoup.cpp:293
#28 0xb54295eb in final_finished (req=0xf5ad2c0, user_data=0x8f1aa60) at soup-session-async.c:331
#29 0xb4e75e84 in IA__g_cclosure_marshal_VOID__VOID (closure=0xfedf598, return_value=0x0, n_param_values=1, param_values=0x8f352c0, 
    invocation_hint=0xbf87924c, marshal_data=0xb5429540) at gmarshal.c:77
#30 0xb4e67fdb in IA__g_closure_invoke (closure=0xfedf598, return_value=0x0, n_param_values=1, param_values=0x8f352c0, invocation_hint=0xbf87924c)
    at gclosure.c:767
#31 0xb4e7fc12 in signal_emit_unlocked_R (node=0x930cfb0, detail=0, instance=0xf5ad2c0, emission_return=0x0, instance_and_params=0x8f352c0)
    at gsignal.c:3314
#32 0xb4e80d5b in IA__g_signal_emit_valist (instance=0xf5ad2c0, signal_id=377, detail=0, 
    var_args=0xbf8793ec "\034\201D�)�A�\034\201D�\030\224\207�;") at gsignal.c:2977
#33 0xb4e81206 in IA__g_signal_emit (instance=0xf5ad2c0, signal_id=377, detail=0) at gsignal.c:3034
#34 0xb541b24f in soup_message_finished (msg=0xf5ad2c0) at soup-message.c:899
#35 0xb542003b in soup_message_io_finished (msg=0xf5ad2c0) at soup-message-io.c:172
#36 0xb4e75e84 in IA__g_cclosure_marshal_VOID__VOID (closure=0xfedec68, return_value=0x0, n_param_values=1, param_values=0xfbaf778, 
    invocation_hint=0xbf8795ac, marshal_data=0xb54206e0) at gmarshal.c:77
#37 0xb4e67fdb in IA__g_closure_invoke (closure=0xfedec68, return_value=0x0, n_param_values=1, param_values=0xfbaf778, invocation_hint=0xbf8795ac)
    at gclosure.c:767
#38 0xb4e7f6e7 in signal_emit_unlocked_R (node=0x94f3b70, detail=0, instance=0xf772170, emission_return=0x0, instance_and_params=0xfbaf778)
    at gsignal.c:3244
#39 0xb4e80d5b in IA__g_signal_emit_valist (instance=0xf772170, signal_id=382, detail=0, 
    var_args=0xbf87974c "�\"���\"�� l�\017x\227\207��\202۴\2309\005\017\001") at gsignal.c:2977
#40 0xb4e81206 in IA__g_signal_emit (instance=0xf772170, signal_id=382, detail=0) at gsignal.c:3034
#41 0xb542b402 in socket_read_watch (chan=0xf053998, cond=<value optimized out>, user_data=0xf772170) at soup-socket.c:1116
#42 0xb4db82bd in g_io_unix_dispatch (source=0xfee6c20, callback=0xb542b3b0 <socket_read_watch>, user_data=0xf772170) at giounix.c:162
#43 0xb4d810c8 in IA__g_main_context_dispatch (context=0x8c06880) at gmain.c:1814
#44 0xb4d8462b in g_main_context_iterate (context=0x8c06880, block=1, dispatch=1, self=0x8bde4b8) at gmain.c:2448
#45 0xb4d84afa in IA__g_main_loop_run (loop=0x8c339c8) at gmain.c:2656
#46 0xb5522f29 in IA__gtk_main () at gtkmain.c:1205
#47 0x08048c86 in main (argc=-1260083744, argv=0xbf87aaa4) at ../../../src/ephy-main.c:781
(gdb)

[Cameron Zwarich (cpst)]

I can't reproduce this on the Mac with the plain iGoogle homepage.

[Cameron Zwarich (cpst)]

I can reproduce this if I log into iGoogle and go to the "Date & Time" gadget page. I'll assign this to myself.

[Geoffrey Garen]

<rdar://problem/6686493>

[Cameron Zwarich (cpst)]

Created attachment 28711 [details]
Steps towards a reduction

This is a lot better than the page itself, but it might be futile to actually reduce this. We'll see.

[Cameron Zwarich (cpst)]

This is a debug-only bug. It is caused by a custom getOwnPropertySlot implementation calling PropertySlot::setUndefined(), which clears m_slotBase in debug builds. I think that setUndefined() shouldn't be calling clearBase(), because of situations like this.

The original intent of the assertion is to catch code that reads the base without setting it. Unfortunately, setUndefined() can be called even after the base has been set, so this assertion is bad. There are two possible fixes:

1) Remove the assertion.

2) Change the assertion so it uses a debug-only bool that records whether m_slotBase was ever set.

I am tending towards option 2, but I need to make a test before I can land anything. I'll mark this as P2 because it's debug-only.

[Cameron Zwarich (cpst)]

Created attachment 28748 [details]
Proposed patch

Here is a different approach.

[Oliver Hunt]

Comment on attachment 28748 [details]
Proposed patch

r=me

[Cameron Zwarich (cpst)]

Landed in r41826.