Bug 72883 – [GTK] SIGSEV when a WebKitDownload fails

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Sergio Villar Senin]

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: ???

[Filip Pizlo]

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]

(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]

(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]

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]

*** Bug 72912 has been marked as a duplicate of this bug. ***

[Filip Pizlo]

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]

(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]

> 
> 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]

(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]

The crash also happens 100% of the time in this (even simpler) page: http://cscs.umich.edu/~crshalizi/weblog/841.html

[Filip Pizlo]

(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]

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]

(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]

(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]

Note, I've now also tested this in 32-bit mode, and still, no crash.

[Sergio Villar Senin]

(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]

(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]

Created attachment 116983 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 116983 [details]
Patch

LGTM

[Xan Lopez]

Comment on attachment 116983 [details]
Patch

OK.

[Sergio Villar Senin]

Comment on attachment 116983 [details]
Patch

Clearing flags on attachment: 116983

Committed r101393: <http://trac.webkit.org/changeset/101393>

[Sergio Villar Senin]

All reviewed patches have been landed.  Closing bug.

[Filip Pizlo]

(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.