Bug 72883

Summary: [GTK] SIGSEV when a WebKitDownload fails
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: JavaScriptCoreAssignee: Sergio Villar Senin <svillar>
Status: RESOLVED FIXED    
Severity: Normal CC: fpizlo, j, mrobinson, ossy, svillar, wingo, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: http://technorati.com
Attachments:
Description Flags
Patch none

Sergio Villar Senin
Reported 2011-11-21 07:30:32 PST
This is what I got from valgrind ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0xACB4EF9: JSC::NumericStrings::add(int) (NumericStrings.h:52) ==4981== by 0xAEBE0C0: JSC::JSValue::toPrimitiveString(JSC::ExecState*) const (JSValue.cpp:212) ==4981== by 0xADE6B9B: cti_op_add (JITStubs.cpp:1327) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x420CF9F: ??? ==4981== by 0xFFFF00000000003F: ??? ==4981== by 0x420D01F: ??? ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0xACB4EF9: JSC::NumericStrings::add(int) (NumericStrings.h:52) ==4981== by 0xAEBE0C0: JSC::JSValue::toPrimitiveString(JSC::ExecState*) const (JSValue.cpp:212) ==4981== by 0xAD5CE08: JSC::jsAdd(JSC::ExecState*, JSC::JSValue, JSC::JSValue) (Operations.h:308) ==4981== by 0xAD570A2: operationValueAdd (DFGOperations.cpp:232) ==4981== by 0x79519334: ??? ==4981== by 0xADC09DD: JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*) (JITCode.h:115) ==4981== by 0xADBD715: JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*) (Interpreter.cpp:1002) ==4981== by 0xAE702D3: JSC::evaluate(JSC::ExecState*, JSC::ScopeChainNode*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) (Completion.cpp:70) ==4981== by 0x718BA2C: WebCore::JSMainThreadExecState::evaluate(JSC::ExecState*, JSC::ScopeChainNode*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) (JSMainThreadExecState.h:58) ==4981== by 0x71C1935: WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) (ScriptController.cpp:146) ==4981== by 0x71C1A39: WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) (ScriptController.cpp:163) ==4981== by 0x73F4CD9: WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) (ScriptElement.cpp:301) ==4981== ASSERTION FAILED: !callLinkInfo->isLinked() ../../Source/JavaScriptCore/jit/JIT.cpp(717) : static void JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::AbstractMacroAssembler<JSC::X86Assembler>::CodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E119C: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x2728951F: ??? ==4981== by 0x420DE1F: ??? ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E35F7: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA982E5: dl_iterate_phdr (dl-iteratephdr.c:75) ==4981== by 0x134E3CE5: _Unwind_Find_FDE (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E11BF: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E35FC: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA982E5: dl_iterate_phdr (dl-iteratephdr.c:75) ==4981== by 0x134E3CE5: _Unwind_Find_FDE (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E11BF: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E3505: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA982E5: dl_iterate_phdr (dl-iteratephdr.c:75) ==4981== by 0x134E3CE5: _Unwind_Find_FDE (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E11BF: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E3533: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA982E5: dl_iterate_phdr (dl-iteratephdr.c:75) ==4981== by 0x134E3CE5: _Unwind_Find_FDE (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E11BF: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== ==4981== Use of uninitialised value of size 8 ==4981== at 0x134E14B6: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x2728951F: ??? ==4981== by 0x420DE1F: ??? ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0x134E14B9: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0x134E21CC: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x2728951F: ??? ==4981== by 0x420DE1F: ??? ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0xEA76B61: backtrace_helper (backtrace.c:68) ==4981== by 0x134E219C: _Unwind_Backtrace (in /lib/x86_64-linux-gnu/libgcc_s.so.1) ==4981== by 0xEA76C3D: backtrace (backtrace.c:91) ==4981== by 0xAEF8F7B: WTFGetBacktrace (Assertions.cpp:168) ==4981== by 0xAEF8FAB: WTFReportBacktrace (Assertions.cpp:197) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x2728951F: ??? ==4981== by 0x420DE1F: ??? ==4981== ==4981== Conditional jump or move depends on uninitialised value(s) ==4981== at 0xAEF906A: WTFReportBacktrace (Assertions.cpp:199) ==4981== by 0xADD30A1: JSC::JIT::linkFor(JSC::JSFunction*, JSC::CodeBlock*, JSC::CodeBlock*, JSC::MacroAssemblerCodePtr, JSC::CallLinkInfo*, JSC::JSGlobalData*, JSC::CodeSpecializationKind) (JIT.cpp:717) ==4981== by 0xADF4380: JSC::lazyLinkFor(JSC::ExecState*, JSC::CodeSpecializationKind) (JITStubs.cpp:2304) ==4981== by 0xADEADC4: cti_vm_lazyLinkCall (JITStubs.cpp:2314) ==4981== by 0xADE6603: JSC::JITThunks::tryCacheGetByID(JSC::ExecState*, JSC::CodeBlock*, JSC::ReturnAddressPtr, JSC::JSValue, JSC::Identifier const&, JSC::PropertySlot const&, JSC::StructureStubInfo*) (JITStubs.cpp:952) ==4981== by 0x7FEFFDB5F: ??? ==4981== by 0x2728951F: ??? ==4981== by 0x420DE1F: ??? ==4981== by 0x2729959F: ???
Attachments
Patch (1.65 KB, patch)
2011-11-29 09:18 PST, Sergio Villar Senin 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Filip Pizlo
Comment 1 2011-11-21 11:06:06 PST
Are you saying that you're getting this assertion whilst running with valgrind? Or are you getting this assertion even when not running with valgrind? Also, what are the steps to reproduce? I visited the attached URL in a debug build of trunk (r100935) and could not see this assertion. Thanks!
Sergio Villar Senin
Comment 2 2011-11-22 03:17:51 PST
(In reply to comment #1) > Are you saying that you're getting this assertion whilst running with valgrind? Or are you getting this assertion even when not running with valgrind? I'm always getting the assertion (with debug builds obviously). I just used valgrind to get the trace. > Also, what are the steps to reproduce? I visited the attached URL in a debug build of trunk (r100935) and could not see this assertion. I'm using WebKitGtk+ which recently got DFG JIT enabled, may be related?
Sergio Villar Senin
Comment 3 2011-11-22 06:35:26 PST
(In reply to comment #2) > (In reply to comment #1) > > Are you saying that you're getting this assertion whilst running with valgrind? Or are you getting this assertion even when not running with valgrind? > > I'm always getting the assertion (with debug builds obviously). I just used valgrind to get the trace. It seems that my above sentence does not properly answer your question. When visiting technorati.com with WebKitGtk+ I always get a SIGSEV, the trace is quite weird as all the pointers seem to be correct (and that code has not been recently changed also). That's why I decided to run it under valgrind, and under those conditions, I always get the assertion mentioned in the title.
Sergio Villar Senin
Comment 4 2011-11-22 06:36:25 PST
This is the trace of the SIGSEV BTW: (gdb) bt #0 0x0000000000000031 in ?? () #1 0x00007ffff5956640 in WebCore::gotChunkCallback (msg=0x2121020, chunk=0x217d6d0, data=0x21fab60) at ../../Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:364 #2 0x00007ffff350b671 in g_cclosure_marshal_VOID__BOXED (closure=0x21fbb20, return_value=0x0, n_param_values=2, param_values=0x1e5a810, invocation_hint=0x7fffffffad80, marshal_data=0x0) at gmarshal.c:574 #3 0x00007ffff3508dc2 in g_closure_invoke (closure=0x21fbb20, return_value=0x0, n_param_values=2, param_values=0x1e5a810, invocation_hint=0x7fffffffad80) at gclosure.c:774 #4 0x00007ffff3522397 in signal_emit_unlocked_R (node=0x1cb1a40, detail=0, instance=0x2121020, emission_return=0x0, instance_and_params=0x1e5a810) at gsignal.c:3302 #5 0x00007ffff3521591 in g_signal_emit_valist (instance=0x2121020, signal_id=453, detail=0, var_args=0x7fffffffb008) at gsignal.c:3033 #6 0x00007ffff3521ae9 in g_signal_emit (instance=0x2121020, signal_id=453, detail=0) at gsignal.c:3090 #7 0x00007ffff3763d8b in soup_message_got_chunk (msg=0x2121020, chunk=0x217d6d0) at soup-message.c:1046 #8 0x00007ffff376983d in read_body_chunk (msg=0x2121020) at soup-message-io.c:516 #9 0x00007ffff376a8a7 in io_read (sock=0x1f978c0, msg=0x2121020) at soup-message-io.c:989 #10 0x00007ffff350aba4 in g_cclosure_marshal_VOID__VOID (closure=0x2139110, return_value=0x0, n_param_values=1, param_values=0x1d400c0, invocation_hint=0x7fffffffd370, marshal_data=0x0) at gmarshal.c:85 #11 0x00007ffff3508dc2 in g_closure_invoke (closure=0x2139110, return_value=0x0, n_param_values=1, param_values=0x1d400c0, invocation_hint=0x7fffffffd370) at gclosure.c:774 #12 0x00007ffff3522397 in signal_emit_unlocked_R (node=0x1ceec30, detail=0, instance=0x1f978c0, emission_return=0x0, instance_and_params=0x1d400c0) at gsignal.c:3302 #13 0x00007ffff3521591 in g_signal_emit_valist (instance=0x1f978c0, signal_id=466, detail=0, var_args=0x7fffffffd5f8) at gsignal.c:3033 #14 0x00007ffff3521ae9 in g_signal_emit (instance=0x1f978c0, signal_id=466, detail=0) at gsignal.c:3090 #15 0x00007ffff377e0f8 in socket_read_watch (pollable=0x1d61d00, user_data=0x1f978c0) at soup-socket.c:1265 #16 0x00007ffff35c0b8a in pollable_source_dispatch (source=0x1ef1e40, callback=0x7ffff377e09b <socket_read_watch>, user_data=0x1f978c0) at gpollableinputstream.c:232 #17 0x00007ffff33fef42 in g_main_dispatch (context=0x544f00) at gmain.c:2513 #18 0x00007ffff33ffc03 in g_main_context_dispatch (context=0x544f00) at gmain.c:3050 #19 0x00007ffff33ffde6 in g_main_context_iterate (context=0x544f00, block=1, dispatch=1, self=0x573d30) at gmain.c:3121 #20 0x00007ffff33ffeaa in g_main_context_iteration (context=0x544f00, may_block=1) at gmain.c:3182 #21 0x00007ffff3601346 in g_application_run (application=0x617000, argc=1, argv=0x7fffffffda88) at gapplication.c:1320 #22 0x0000000000430ca2 in main (argc=1, argv=0x7fffffffda88) at ../../src/ephy-main.c:472
Sergio Villar Senin
Comment 5 2011-11-22 06:37:03 PST
*** Bug 72912 has been marked as a duplicate of this bug. ***
Filip Pizlo
Comment 6 2011-11-22 13:38:04 PST
This trace looks like the JIT emitted a jump to an invalid location (0x0000000000000031) and we're faulting because that pointer contains no executable (or readable, or writable, even) memory. I'm not sure if the assertion you're seeing is informative; it might just be valgrind interacting strangely with JSC's code patching logic. I visited the technorati.com site on the Mac port and did not get any crashes. Does yours crash upon visiting the site, or only after you navigate around for a bit? (In reply to comment #4) > This is the trace of the SIGSEV BTW: > (gdb) bt > #0 0x0000000000000031 in ?? () > #1 0x00007ffff5956640 in WebCore::gotChunkCallback (msg=0x2121020, chunk=0x217d6d0, data=0x21fab60) > at ../../Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:364 > #2 0x00007ffff350b671 in g_cclosure_marshal_VOID__BOXED (closure=0x21fbb20, return_value=0x0, n_param_values=2, param_values=0x1e5a810, > invocation_hint=0x7fffffffad80, marshal_data=0x0) at gmarshal.c:574 > #3 0x00007ffff3508dc2 in g_closure_invoke (closure=0x21fbb20, return_value=0x0, n_param_values=2, param_values=0x1e5a810, > invocation_hint=0x7fffffffad80) at gclosure.c:774 > #4 0x00007ffff3522397 in signal_emit_unlocked_R (node=0x1cb1a40, detail=0, instance=0x2121020, emission_return=0x0, > instance_and_params=0x1e5a810) at gsignal.c:3302 > #5 0x00007ffff3521591 in g_signal_emit_valist (instance=0x2121020, signal_id=453, detail=0, var_args=0x7fffffffb008) at gsignal.c:3033 > #6 0x00007ffff3521ae9 in g_signal_emit (instance=0x2121020, signal_id=453, detail=0) at gsignal.c:3090 > #7 0x00007ffff3763d8b in soup_message_got_chunk (msg=0x2121020, chunk=0x217d6d0) at soup-message.c:1046 > #8 0x00007ffff376983d in read_body_chunk (msg=0x2121020) at soup-message-io.c:516 > #9 0x00007ffff376a8a7 in io_read (sock=0x1f978c0, msg=0x2121020) at soup-message-io.c:989 > #10 0x00007ffff350aba4 in g_cclosure_marshal_VOID__VOID (closure=0x2139110, return_value=0x0, n_param_values=1, param_values=0x1d400c0, > invocation_hint=0x7fffffffd370, marshal_data=0x0) at gmarshal.c:85 > #11 0x00007ffff3508dc2 in g_closure_invoke (closure=0x2139110, return_value=0x0, n_param_values=1, param_values=0x1d400c0, > invocation_hint=0x7fffffffd370) at gclosure.c:774 > #12 0x00007ffff3522397 in signal_emit_unlocked_R (node=0x1ceec30, detail=0, instance=0x1f978c0, emission_return=0x0, > instance_and_params=0x1d400c0) at gsignal.c:3302 > #13 0x00007ffff3521591 in g_signal_emit_valist (instance=0x1f978c0, signal_id=466, detail=0, var_args=0x7fffffffd5f8) at gsignal.c:3033 > #14 0x00007ffff3521ae9 in g_signal_emit (instance=0x1f978c0, signal_id=466, detail=0) at gsignal.c:3090 > #15 0x00007ffff377e0f8 in socket_read_watch (pollable=0x1d61d00, user_data=0x1f978c0) at soup-socket.c:1265 > #16 0x00007ffff35c0b8a in pollable_source_dispatch (source=0x1ef1e40, callback=0x7ffff377e09b <socket_read_watch>, user_data=0x1f978c0) > at gpollableinputstream.c:232 > #17 0x00007ffff33fef42 in g_main_dispatch (context=0x544f00) at gmain.c:2513 > #18 0x00007ffff33ffc03 in g_main_context_dispatch (context=0x544f00) at gmain.c:3050 > #19 0x00007ffff33ffde6 in g_main_context_iterate (context=0x544f00, block=1, dispatch=1, self=0x573d30) at gmain.c:3121 > #20 0x00007ffff33ffeaa in g_main_context_iteration (context=0x544f00, may_block=1) at gmain.c:3182 > #21 0x00007ffff3601346 in g_application_run (application=0x617000, argc=1, argv=0x7fffffffda88) at gapplication.c:1320 > #22 0x0000000000430ca2 in main (argc=1, argv=0x7fffffffda88) at ../../src/ephy-main.c:472
Sergio Villar Senin
Comment 7 2011-11-23 01:14:20 PST
(In reply to comment #6) > This trace looks like the JIT emitted a jump to an invalid location (0x0000000000000031) and we're faulting because that pointer contains no executable (or readable, or writable, even) memory. > > I'm not sure if the assertion you're seeing is informative; it might just be valgrind interacting strangely with JSC's code patching logic. Yeah it might be the case, because I never hit the assertion running it only with the debugger, just when it's run under valgrind. > I visited the technorati.com site on the Mac port and did not get any crashes. Does yours crash upon visiting the site, or only after you navigate around for a bit? Just visiting the site, looks like at the very end of the loading process. But it is not the unique case, for example a colleague of mine got it here http://javierparra.eu/?p=721 (bug 72912). Just ping me on IRC (svillar) and I'd be glad to help debugging the issue.
Filip Pizlo
Comment 8 2011-11-23 01:20:18 PST
> > Just visiting the site, looks like at the very end of the loading process. But it is not the unique case, for example a colleague of mine got it here http://javierparra.eu/?p=721 (bug 72912). > > Just ping me on IRC (svillar) and I'd be glad to help debugging the issue. I will look into this. But apologies if I don't get around to it until Monday, since I am technically on holiday. :-)
Sergio Villar Senin
Comment 9 2011-11-23 01:31:22 PST
(In reply to comment #8) > > > > Just visiting the site, looks like at the very end of the loading process. But it is not the unique case, for example a colleague of mine got it here http://javierparra.eu/?p=721 (bug 72912). > > > > Just ping me on IRC (svillar) and I'd be glad to help debugging the issue. > > I will look into this. But apologies if I don't get around to it until Monday, since I am technically on holiday. :-) Heh don't worry, enjoy your holidays!
Xan Lopez
Comment 10 2011-11-24 15:37:09 PST
The crash also happens 100% of the time in this (even simpler) page: http://cscs.umich.edu/~crshalizi/weblog/841.html
Filip Pizlo
Comment 11 2011-11-24 16:16:06 PST
(In reply to comment #10) > The crash also happens 100% of the time in this (even simpler) page: http://cscs.umich.edu/~crshalizi/weblog/841.html This is good to know - thanks for your help in reducing this bug! :-)
Filip Pizlo
Comment 12 2011-11-28 09:42:49 PST
I looked into this using r101263 and the Mac port. I cannot get a crash on any of the three sites mentioned: technorati.com, http://javierparra.eu/?p=721, or http://cscs.umich.edu/~crshalizi/weblog/841.html. Perhaps this is a GTK+ issue?
Martin Robinson
Comment 13 2011-11-28 09:46:09 PST
(In reply to comment #12) > I looked into this using r101263 and the Mac port. I cannot get a crash on any of the three sites mentioned: technorati.com, http://javierparra.eu/?p=721, or http://cscs.umich.edu/~crshalizi/weblog/841.html. > > Perhaps this is a GTK+ issue? From what I understand it didn't appear until we turned on the DFG JIT. If it would be helpful we can arrange an interactive debugging session over the IRC channel.
Filip Pizlo
Comment 14 2011-11-28 09:49:17 PST
(In reply to comment #13) > (In reply to comment #12) > > I looked into this using r101263 and the Mac port. I cannot get a crash on any of the three sites mentioned: technorati.com, http://javierparra.eu/?p=721, or http://cscs.umich.edu/~crshalizi/weblog/841.html. > > > > Perhaps this is a GTK+ issue? > > From what I understand it didn't appear until we turned on the DFG JIT. If it would be helpful we can arrange an interactive debugging session over the IRC channel. Yup, I'd be happy to help.
Filip Pizlo
Comment 15 2011-11-28 16:34:38 PST
Note, I've now also tested this in 32-bit mode, and still, no crash.
Sergio Villar Senin
Comment 16 2011-11-28 17:28:43 PST
(In reply to comment #15) > Note, I've now also tested this in 32-bit mode, and still, no crash. hmm I tried disabling DFG and the crash is still here, so maybe you're right and there is something Gtk specific
Sergio Villar Senin
Comment 17 2011-11-29 09:09:37 PST
(In reply to comment #15) > Note, I've now also tested this in 32-bit mode, and still, no crash. Sorry for the noise Filip, at the end it was indeed a GTK issue
Sergio Villar Senin
Comment 18 2011-11-29 09:18:16 PST
Created attachment 116983 [details] Patch
Carlos Garcia Campos
Comment 19 2011-11-29 09:20:49 PST
Comment on attachment 116983 [details] Patch LGTM
Xan Lopez
Comment 20 2011-11-29 09:28:46 PST
Comment on attachment 116983 [details] Patch OK.
Sergio Villar Senin
Comment 21 2011-11-29 09:36:59 PST
Comment on attachment 116983 [details] Patch Clearing flags on attachment: 116983 Committed r101393: <http://trac.webkit.org/changeset/101393>
Sergio Villar Senin
Comment 22 2011-11-29 09:37:13 PST
All reviewed patches have been landed. Closing bug.
Filip Pizlo
Comment 23 2011-11-29 12:35:47 PST
(In reply to comment #17) > (In reply to comment #15) > > Note, I've now also tested this in 32-bit mode, and still, no crash. > > Sorry for the noise Filip, at the end it was indeed a GTK issue No worries! Glad that this is now resolved.
Note You need to log in before you can comment on or make changes to this bug.