| Summary: | [EFL] fast/files/xhr-response-blob.html is crashing | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||
| Component: | WebKit EFL | Assignee: | Chris Dumez <cdumez> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | gyuyoung.kim, haraken, kinuko, lucas.de.marchi, rakuco, tony, webkit.review.bot | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Chris Dumez
2012-06-18 00:35:38 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 #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?)
Created attachment 148071 [details]
Patch
Comment on attachment 148071 [details]
Patch
Thanks for fixing the crash! The change looks good to me though I'm not a reviewer.
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? 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... 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? (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.) chromium port also returns "application/javascript". (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 Comment on attachment 148071 [details]
Patch
Makes sense. Let's fix the crash first.
(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. (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! Comment on attachment 148071 [details] Patch Clearing flags on attachment: 148071 Committed r120581: <http://trac.webkit.org/changeset/120581> All reviewed patches have been landed. Closing bug. |