Bug 89334 – [EFL] fast/files/xhr-response-blob.html is crashing

• Component: WebKit EFL
• Status: RESOLVED FIXED

[Chris Dumez]

fast/files/xhr-response-blob.html is crashing for EFL port.

[Chris Dumez]

Backtrace:

crash log for DumpRenderTree (pid 18042):
STDOUT: <empty>
STDERR: ASSERTION FAILED: !getCachedWrapper(currentWorld(exec), node)
STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug/build/Source/WebCore/bindings/js/JSDOMBinding.h(161) : WebCore::JSDOMWrapper* WebCore::createWrapper(JSC::ExecState*, WebCore::JSDOMGlobalObject*, DOMClass*) [with WrapperClass = WebCore::JSBlob, DOMClass = WebCore::Blob]
STDERR: 1   0x7f64f0789efa WebCore::JSDOMWrapper* WebCore::createWrapper<WebCore::JSBlob, WebCore::Blob>(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Blob*)
STDERR: 2   0x7f64f0787f39 WebCore::toJS(JSC::ExecState*, WebCore::JSDOMGlobalObject*, WebCore::Blob*)
STDERR: 3   0x7f64f07e99f5 WebCore::JSXMLHttpRequest::response(JSC::ExecState*) const
STDERR: 4   0x7f64f0a5ca9a WebCore::jsXMLHttpRequestResponse(JSC::ExecState*, JSC::JSValue, JSC::PropertyName)
STDERR: 5   0x48f311 JSC::PropertySlot::getValue(JSC::ExecState*, JSC::PropertyName) const
STDERR: 6   0x7f64f40d300d JSC::JSValue::get(JSC::ExecState*, JSC::PropertyName, JSC::PropertySlot&) const
STDERR: 7   0x7f64f4186ed7
STDERR: 8   0x7f64f4184e1d
STDERR: 9   0x7fff2c3332e0

[Chris Dumez]

#0  0x00007ffff3d8dbe4 in WebCore::createWrapper<WebCore::JSBlob, WebCore::Blob> (exec=0x7fffa06a71a0, globalObject=0x7ffff7e4f680, node=0x8d0fc0)
    at /home/chris/Devel/WebKit/Source/WebCore/bindings/js/JSDOMBinding.h:161
#1  0x00007ffff3d8bc19 in WebCore::toJS (exec=0x7fffa06a71a0, globalObject=0x7ffff7e4f680, blob=0x8d0fc0) at /home/chris/Devel/WebKit/Source/WebCore/bindings/js/JSBlobCustom.cpp:59
#2  0x00007ffff3ded6d5 in WebCore::JSXMLHttpRequest::response (this=0x7ffff7e6ebc0, exec=0x7fffa06a71a0) at /home/chris/Devel/WebKit/Source/WebCore/bindings/js/JSXMLHttpRequestCustom.cpp:182
#3  0x00007ffff4060772 in WebCore::jsXMLHttpRequestResponse (exec=0x7fffa06a71a0, slotBase=...) at /home/chris/Devel/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/JSXMLHttpRequest.cpp:407
#4  0x000000000048f2c1 in JSC::PropertySlot::getValue (this=0x7fffffffbd50, exec=0x7fffa06a71a0, propertyName=...) at /home/chris/Devel/WebKit/Source/JavaScriptCore/runtime/PropertySlot.h:75
#5  0x00007ffff7605fd9 in JSC::JSValue::get (this=0x7fffffffbda0, exec=0x7fffa06a71a0, propertyName=..., slot=...) at /home/chris/Devel/WebKit/Source/JavaScriptCore/runtime/JSObject.h:819
#6  0x00007ffff76b9ea3 in JSC::cti_op_get_by_id (args=0x7fffffffbe10) at /home/chris/Devel/WebKit/Source/JavaScriptCore/jit/JITStubs.cpp:1672
#7  0x00007ffff76b7de9 in JSC::JITThunks::tryCacheGetByID (callFrame=0x7fffa06a71a0, codeBlock=0x7fffffffbd50, returnAddress=..., baseValue=..., propertyName=..., slot=..., stubInfo=0x7ffff7e6ebc0)
    at /home/chris/Devel/WebKit/Source/JavaScriptCore/jit/JITStubs.cpp:967
#8  0x00007fffffffbe40 in ?? ()
#9  0x00007ffff7e6ebc0 in ?? ()
#10 0x0000000000bc54c8 in ?? ()
#11 0x00007ffff750ad93 in JSC::Register::Register (this=0xd0f5e8c78948104d) at /home/chris/Devel/WebKit/Source/JavaScriptCore/interpreter/Register.h:105
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

[Chris Dumez]

Created attachment 148071 [details]
Patch

[Kinuko Yasuda]

Comment on attachment 148071 [details]
Patch

Thanks for fixing the crash! The change looks good to me though I'm not a reviewer.

[Kentaro Hara]

Comment on attachment 148071 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=148071&action=review

The change in JSBlobCustom.cpp looks OK.

> LayoutTests/platform/efl/fast/files/xhr-response-blob-expected.txt:13
> +FAIL xhr.response.type should be text/javascript. Was application/javascript.

Is it OK to leave this FAIL line?

[Kinuko Yasuda]

Comment on attachment 148071 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=148071&action=review

>> LayoutTests/platform/efl/fast/files/xhr-response-blob-expected.txt:13
>> +FAIL xhr.response.type should be text/javascript. Was application/javascript.
> 
> Is it OK to leave this FAIL line?

Looks like this part could differ depending on platforms (it calls platform-specific code).  Per RFC text/javascript is actually obsolete but Mac code returns it...

[Kentaro Hara]

Comment on attachment 148071 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=148071&action=review

>>> LayoutTests/platform/efl/fast/files/xhr-response-blob-expected.txt:13
>>> +FAIL xhr.response.type should be text/javascript. Was application/javascript.
>> 
>> Is it OK to leave this FAIL line?
> 
> Looks like this part could differ depending on platforms (it calls platform-specific code).  Per RFC text/javascript is actually obsolete but Mac code returns it...

Shall we file the bug, and then change "text/javascript" to "text/plain" so that the result of this test does not depend on platforms?

[Kentaro Hara]

(In reply to comment #7)
> > Looks like this part could differ depending on platforms (it calls platform-specific code).  Per RFC text/javascript is actually obsolete but Mac code returns it...
> 
> Shall we file the bug, and then change "text/javascript" to "text/plain" so that the result of this test does not depend on platforms?

Ah, sorry. this is a blob for javascript, and thus the blob type should be "text/javascript".

So, shall we commit it for now and dig into it later? (Fixing the crash would be more important.)

[Chris Dumez]

chromium port also returns "application/javascript".

[Kinuko Yasuda]

(In reply to comment #9)
> chromium port also returns "application/javascript".

Chromium port resturns application/x-javascript as far as I know...

I'd like to change the test in a separate bug but would like this to land first, since crashing is bad (and this is happening on all platforms that use JSC).
Filed a new bug: bug 89338

[Kentaro Hara]

Comment on attachment 148071 [details]
Patch

Makes sense. Let's fix the crash first.

[Chris Dumez]

(In reply to comment #10)
> (In reply to comment #9)
> > chromium port also returns "application/javascript".
> 
> Chromium port resturns application/x-javascript as far as I know...
> 
> I'd like to change the test in a separate bug but would like this to land first, since crashing is bad (and this is happening on all platforms that use JSC).
> Filed a new bug: bug 89338

I was referring to chromium-linux. It does return "application/javascript" according to its expected result.

[Kinuko Yasuda]

(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > chromium port also returns "application/javascript".
> > 
> > Chromium port resturns application/x-javascript as far as I know...
> > 
> > I'd like to change the test in a separate bug but would like this to land first, since crashing is bad (and this is happening on all platforms that use JSC).
> > Filed a new bug: bug 89338
> 
> I was referring to chromium-linux. It does return "application/javascript" according to its expected result.

I see, thanks for the correction.  MIME types for javascript is complicated!

[WebKit Review Bot]

Comment on attachment 148071 [details]
Patch

Clearing flags on attachment: 148071

Committed r120581: <http://trac.webkit.org/changeset/120581>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.