Bug 115949 – Window Object TypeError: 'undefined' is not an object (evaluating 'this.document')

• Status: UNCONFIRMED
• Component: JavaScriptCore

[Youngho Yoo]

Overview :

Window Object TypeError: 'undefined' is not an object (evaluating 'this.document') in www.pikaboo.be

Steps to Reproduce:

1. go to http://www.pikaboo.be
2. click the Music Videos in the list of the categories on the slightly bottom of the right
3. When the video thumnails are loaded, click one of them to see the video

Actual Results:

there is no response and no pop-up.
Inspector shows TypeError: 'undefined' is not an object (evaluating 'this.document'), this = Window object

Expected Results:

It is supposed to be poped up the message, 
poped up the message : You must install the QuickTime browser plugin to view this content 
( because I didn't install that)

Build Date & Platform:

Linux, Qt, WebKit2, ARM_THUMB2 with LLInt + JIT + DFG_JIT (rev 149600)
I tested ARM_TRADITIONAL and it happens also.

Additional Builds and Platforms:

Doesn't Occur on Linux(Ubuntu), Qt, WebKit2, X86 with LLInt + JIT + DFG_JIT (rev 149600)

Additional Information:

w/o DFG_JIT It doesn't occur.

TypeError throwException call stack(In DFG)

throwExceptionFromCallSlowPathGenerator(dfg/DFGThunks.cpp)
->lookupExceptionHandlerInStub(dfg/DFGOperations.cpp)
->genericThrow(jit/JITExceptions.cpp)
->throwException(interpreter/Interpreter.cpp)

it return 0 at throwException(interpreter/Interpreter.cpp)(rev 149600(line 767))

[Mark Lam]

Can you test with a webkit nightly (http://nightly.webkit.org) on Mac and see if it manifests there too?

[Byungseon Shin]

It doesn't occur in webkit nightly on Mac.

[Youngho Yoo]

there is wrong call stack.
here is correct call stack about TypeError throwException call stack(In DFG)

compileExceptionHandlers(dfg/DFGJITCompiler.cpp)
->lookupExceptionHandler(dfg/DFGOperations.cpp)
->genericThrow(jit/JITExceptions.cpp)
->throwException(interpreter/Interpreter.cpp)

as you know, this is not call stack, It is flow of excution, because this split up compilation and execution.

[Youngho Yoo]

Add more flows.

->compile(dfg/DFGDriver.cpp)
->compileFunction(dfg/DFGJITCompiler.cpp)
->compileExceptionHandlers(dfg/DFGJITCompiler.cpp)
->lookupExceptionHandler(dfg/DFGOperations.cpp)
->genericThrow(jit/JITExceptions.cpp)
->throwException(interpreter/Interpreter.cpp)

[Mark Lam]

(In reply to comment #0)
> TypeError throwException call stack(In DFG)
> 
> throwExceptionFromCallSlowPathGenerator(dfg/DFGThunks.cpp)
> ->lookupExceptionHandlerInStub(dfg/DFGOperations.cpp)
> ->genericThrow(jit/JITExceptions.cpp)
> ->throwException(interpreter/Interpreter.cpp)
> 
> it return 0 at throwException(interpreter/Interpreter.cpp)(rev 149600(line 767))

Since this happens (presumably repeatably) in throwException(), why don't you step thru that code and find out what conditions led to it returning 0?

Once you know that, for contrast, do the same on your Ubuntu port and see what is different such that it results in it not returning 0.

You can also try calling Interpreter::dumpCallFrame() for each frame in that unwind loop and see if that gives you any extra info.  But basically, you need to do the above steps to figure out what is different between the working and failing port.  That will tell you where to look next.

[Mark Lam]

(In reply to comment #5)
> You can also try calling Interpreter::dumpCallFrame() for each frame in that unwind loop and see if that gives you any extra info.  But basically, you need to do the above steps to figure out what is different between the working and failing port.  That will tell you where to look next.

You can also compare between what happens in throwException() with the DFG enabled and with the DFG disabled.  In case you didn't know, you can trivially disable the DFG by setting Options::useDFGJIT() = false in Options.cpp (search for "useDFGJIT").

[Youngho Yoo]

(In reply to comment #6)

I found what was a problem.

in Source/JavaScriptCore/dfg/DFGFixupPhase.cpp,
void fixupNode(Node* node) function.
case GetById: 

If I remove setUseKindAndUnboxIfProfitable<CellUse>(node->child1());,
then There is no TypeError.

There is some traditional compiler optimzing method, name was liveness analysis.
And setUseKindAndUnboxIfProfitable role is marking for doing liveness analysis.
I don't know yet this is only the our platform problem or not.
But if we doing liveness analysis with HTMLDocument(in Top object) object,
It will unbox(remove) that object when even if JSC still needs that object.

I will check this problem in detail.