Bug 28438 – Browser hangs on opening Web Inspector.

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector (Deprecated)

[Pavel Feldman]

1. Open Web Inspector

Expected: All Ok
Actual: Browser hangs:

#0	0x006a59f7 in WTF::HashTable<WTF::RefPtr<JSC::UString::Rep>, std::pair<WTF::RefPtr<JSC::UString::Rep>, JSC::SymbolTableEntry>, WTF::PairFirstExtractor<std::pair<WTF::RefPtr<JSC::UString::Rep>, JSC::SymbolTableEntry> >, JSC::IdentifierRepHash, WTF::PairHashTraits<WTF::HashTraits<WTF::RefPtr<JSC::UString::Rep> >, JSC::SymbolTableIndexHashTraits>, WTF::HashTraits<WTF::RefPtr<JSC::UString::Rep> > >::lookup<JSC::UString::Rep*, WTF::RefPtrHashMapRawKeyTranslator<JSC::UString::Rep*, std::pair<WTF::RefPtr<JSC::UString::Rep>, JSC::SymbolTableEntry>, WTF::PairHashTraits<WTF::HashTraits<WTF::RefPtr<JSC::UString::Rep> >, JSC::SymbolTableIndexHashTraits>, JSC::IdentifierRepHash> > at HashTable.h:486
#1	0x006a5a88 in WTF::HashMap<WTF::RefPtr<JSC::UString::Rep>, JSC::SymbolTableEntry, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<JSC::UString::Rep> >, JSC::SymbolTableIndexHashTraits>::inlineGet at RefPtrHashMap.h:270
#2	0x006a5cd2 in WTF::HashMap<WTF::RefPtr<JSC::UString::Rep>, JSC::SymbolTableEntry, JSC::IdentifierRepHash, WTF::HashTraits<WTF::RefPtr<JSC::UString::Rep> >, JSC::SymbolTableIndexHashTraits>::get at RefPtrHashMap.h:280
#3	0x00610863 in JSC::BytecodeGenerator::findScopedProperty at BytecodeGenerator.cpp:987
#4	0x006214d4 in JSC::FunctionCallResolveNode::emitBytecode at Nodes.cpp:348
#5	0x006b26d9 in JSC::BytecodeGenerator::emitNode at BytecodeGenerator.h:178
#6	0x00624f9d in JSC::ExprStatementNode::emitBytecode at Nodes.cpp:1278
#7	0x006b26d9 in JSC::BytecodeGenerator::emitNode at BytecodeGenerator.h:178
#8	0x00621aa2 in JSC::statementListEmitCode at Nodes.cpp:1245
#9	0x00621e8b in JSC::BlockNode::emitBytecode at Nodes.cpp:1252
#10	0x006b26d9 in JSC::BytecodeGenerator::emitNode at BytecodeGenerator.h:178
#11	0x00621aa2 in JSC::statementListEmitCode at Nodes.cpp:1245
#12	0x00621b0c in JSC::FunctionBodyNode::emitBytecode at Nodes.cpp:1985
#13	0x00610503 in JSC::BytecodeGenerator::generate at BytecodeGenerator.cpp:144
#14	0x00767730 in JSC::FunctionExecutable::generateBytecode at Executable.cpp:87
#15	0x006de33f in JSC::FunctionExecutable::bytecode at Executable.h:212
#16	0x006cae27 in JSC::Interpreter::execute at Interpreter.cpp:701
#17	0x0062c4de in JSC::JSFunction::call at JSFunction.cpp:122
#18	0x0062c5b9 in JSC::call at CallData.cpp:39
#19	0x040e109e in WebCore::ScheduledAction::executeFunctionInContext at ScheduledAction.cpp:105
#20	0x040e1419 in WebCore::ScheduledAction::execute at ScheduledAction.cpp:125
#21	0x040e14e3 in WebCore::ScheduledAction::execute at ScheduledAction.cpp:76
#22	0x03b4f685 in WebCore::DOMTimer::fired at DOMTimer.cpp:124
#23	0x04220f01 in WebCore::ThreadTimers::fireTimers at ThreadTimers.cpp:111
#24	0x0422111d in WebCore::ThreadTimers::sharedTimerFiredInternal at ThreadTimers.cpp:141
#25	0x04221169 in WebCore::ThreadTimers::sharedTimerFired at ThreadTimers.cpp:122
#26	0x04110c38 in WebCore::timerFired at SharedTimerMac.mm:86
#27	0x93e0f8f5 in CFRunLoopRunSpecific
#28	0x93e0faa8 in CFRunLoopRunInMode
#29	0x943a72ac in RunCurrentEventLoopInMode
#30	0x943a70c5 in ReceiveNextEventCommon
#31	0x943a6f39 in BlockUntilNextEventMatchingListInMode
#32	0x94b496d5 in _DPSNextEvent
#33	0x94b48f88 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#34	0x0000c303 in ??
#35	0x94b41f9f in -[NSApplication run]
#36	0x94b0f1d8 in NSApplicationMain
#37	0x00002c92 in ??

[Pavel Feldman]

Reverting r47412 [by [e-mail]] fixes the issue.

[Joseph Pecoraro]

I got the following with gdb:

  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_PROTECTION_FAILURE at address: 0x00000008
  0x00611f6f in JSC::MarkStack::appendValues () at /Users/joe/WebKit/JavaScriptCore/runtime/JSActivation.cpp:63
  63	    markStack.appendValues(registerArray, count);

[Gavin Barraclough]

Cannot reproduce the bug.
What platform are you on / what websites can you repro the issue on?  Is this 100% reproducible for you?

[Pavel Feldman]

(In reply to comment #3)
> Cannot reproduce the bug.
> What platform are you on / what websites can you repro the issue on?  Is this
> 100% reproducible for you?

- 100% reproducible
- any site, try google.com
- Mac OS 10.5.8, Safari 4.0.3, 32bit.

I know Joseph had to revert your change since it was hitting him as well.

[Oliver Hunt]

I suspect (based on the backtrace) that the hang is actually ReportCrash taking forever to analyse a debug build.

The issue is that when debugging is enabled all the codeblocks for all existing functions get erased.  Now if we imagine a scenario:

    function createClosure() {
        var a = "Argh!!";
        return function() {
            return a;
        }
    }

    closure = createClosure();

Now we enable debugging, so neither the closure function nor the createClosure function retain their code blocks.  At this point we call 'closure()', which triggers recompilation of the closure function which requires a lookup of a, which then crashes as a scope lookup uses the symbol table of the (now deleted) code block of the createClosure function.

Happily i have a fix that i shall post shortly.

[Oliver Hunt]

Created attachment 38365 [details]
Patch v1

[Maciej Stachowiak]

Comment on attachment 38365 [details]
Patch v1

r=me

[Oliver Hunt]

Committed r47627