WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
89334
[EFL] fast/files/xhr-response-blob.html is crashing
https://bugs.webkit.org/show_bug.cgi?id=89334
Summary
[EFL] fast/files/xhr-response-blob.html is crashing
Chris Dumez
Reported
2012-06-18 00:35:38 PDT
fast/files/xhr-response-blob.html is crashing for EFL port.
Attachments
Patch
(3.86 KB, patch)
2012-06-18 01:30 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2012-06-18 00:43:28 PDT
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
Comment 2
2012-06-18 01:10:44 PDT
#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
Comment 3
2012-06-18 01:30:50 PDT
Created
attachment 148071
[details]
Patch
Kinuko Yasuda
Comment 4
2012-06-18 01:51:53 PDT
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 5
2012-06-18 02:01:02 PDT
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 6
2012-06-18 02:15:56 PDT
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 7
2012-06-18 02:24:20 PDT
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
Comment 8
2012-06-18 02:26:23 PDT
(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
Comment 9
2012-06-18 02:31:04 PDT
chromium port also returns "application/javascript".
Kinuko Yasuda
Comment 10
2012-06-18 02:35:06 PDT
(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 11
2012-06-18 02:36:11 PDT
Comment on
attachment 148071
[details]
Patch Makes sense. Let's fix the crash first.
Chris Dumez
Comment 12
2012-06-18 02:38:02 PDT
(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
Comment 13
2012-06-18 02:40:36 PDT
(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 14
2012-06-18 03:04:16 PDT
Comment on
attachment 148071
[details]
Patch Clearing flags on attachment: 148071 Committed
r120581
: <
http://trac.webkit.org/changeset/120581
>
WebKit Review Bot
Comment 15
2012-06-18 03:04:24 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug