Bug 112694

The stacktrace points to DFG JIT: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffe1803700 (LWP 7200)] 0x00007ffff1e6e7a4 in JSC::DFG::Node::hasResult (this=0x1) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGNode.h:622 622 return m_flags & NodeResultMask; (gdb) bt #0 0x00007ffff1e6e7a4 in JSC::DFG::Node::hasResult (this=0x1) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGNode.h:622 #1 0x00007ffff1f25412 in JSC::DFG::ScoreBoard::useIfHasResult (this=0x7fffffffb200, child=...) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGScoreBoard.h:136 #2 0x00007ffff1f25678 in JSC::DFG::VirtualRegisterAllocationPhase::run (this=0x7fffffffb4f0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGVirtualRegisterAllocationPhase.cpp:94 #3 0x00007ffff1f26327 in JSC::DFG::runAndLog<JSC::DFG::VirtualRegisterAllocationPhase> (phase=...) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGPhase.h:75 #4 0x00007ffff1f25d8e in JSC::DFG::runPhase<JSC::DFG::VirtualRegisterAllocationPhase> (graph=...) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGPhase.h:85 #5 0x00007ffff1f24d1b in JSC::DFG::performVirtualRegisterAllocation (graph=...) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGVirtualRegisterAllocationPhase.cpp:146 #6 0x00007ffff1e8056a in JSC::DFG::compile (compileMode=JSC::DFG::CompileFunction, exec=0x7fff833ff558, codeBlock=0x13d85e0, jitCode=..., jitCodeWithArityCheck=0x7fff830f12c0, osrEntryBytecodeIndex=0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGDriver.cpp:145 #7 0x00007ffff1e7fe28 in JSC::DFG::tryCompileFunction (exec=0x7fff833ff558, codeBlock=0x13d85e0, jitCode=..., jitCodeWithArityCheck=..., bytecodeIndex=0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/dfg/DFGDriver.cpp:179 #8 0x00007ffff201a49d in JSC::jitCompileFunctionIfAppropriate (exec=0x7fff833ff558, codeBlock=..., jitCode=..., jitCodeWithArityCheck=..., jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0, effort=JSC::JITCompilationCanFail) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/jit/JITDriver.h:95 #9 0x00007ffff201a78f in JSC::prepareFunctionForExecution (exec=0x7fff833ff558, codeBlock=..., jitCode=..., jitCodeWithArityCheck=..., jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0, kind=JSC::CodeForCall) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/runtime/ExecutionHarness.h:68 #10 0x00007ffff20189de in JSC::FunctionExecutable::compileForCallInternal (this=0x7fff830f1270, exec=0x7fff833ff558, scope=0x7fff9809ec70, jitType=JSC::JITCode::DFGJIT, bytecodeIndex=0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/runtime/Executable.cpp:538 #11 0x00007ffff201815b in JSC::FunctionExecutable::compileOptimizedForCall (this=0x7fff830f1270, exec=0x7fff833ff558, scope=0x7fff9809ec70, bytecodeIndex=0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/runtime/Executable.cpp:463 #12 0x00007ffff1d65aaf in JSC::FunctionExecutable::compileOptimizedFor (this=0x7fff830f1270, exec=0x7fff833ff558, scope=0x7fff9809ec70, bytecodeIndex=0, kind=JSC::CodeForCall) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/runtime/Executable.h:678 #13 0x00007ffff1d6045e in JSC::FunctionCodeBlock::compileOptimized (this=0xc1c520, exec=0x7fff833ff558, scope=0x7fff9809ec70, bytecodeIndex=0) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/bytecode/CodeBlock.cpp:2879 #14 0x00007ffff1f610ae in JSC::cti_optimize (args=0x7fffffffcf50) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/jit/JITStubs.cpp:1899 #15 0x00007ffff1f5e0cd in JSC::tryCacheGetByID (callFrame=0x7fff833ff558, codeBlock=0x7fff9809ec70, returnAddress=..., baseValue=..., propertyName=..., slot=..., stubInfo=0x7fff00000000) at /home/abecsi/devel/git/webkit-git-svn/Source/JavaScriptCore/jit/JITStubs.cpp:996 #16 0x00007fff833ff058 in ?? ()

Note that the QNetworkReplyImplPrivate::error is unrelated to the crash.

I can reproduce this in a WebKit nightly as well.

<rdar://problem/13452460>

Have reduced this down to one function that we are crashing while compiling in the DFG. The source is: function (c, u, f) { if (c == null || c.visible != true) return []; var n = [], t = a.fitInRange(c.offset, 0, 1), v = c.length, e = this.cx, g = this.cy, x = e, r = g - t * this.radius, y = e, z = r - v; if (!Array.prototype.filter) Array.prototype.filter = function (c) { "use strict"; if (this === void 0 || this === null) throw new TypeError; var b = Object(this), g = b.length >>> 0; if (typeof c !== "function") throw new TypeError; for (var d = [], f = arguments[1], a = 0; a < g; a++) if (a in b) { var e = b[a]; c.call(f, e, a, b) && d.push(e) } return d }; if (u === false) { var s = this._getMarkInterval(c, false), l = this._getIntervals(s, c, false); if (f.visible === true) { var m = this._getMarkInterval(f, true), j = this._getIntervals(m, f, true), i = []; <===== Appears we are dying after eliminating the NewArray node here i = l.filter(function (a) { return b.inArray(a, j) === -1 }); intrs = i } else intrs = l } else { var m = this._getMarkInterval(c, true), j = this._getIntervals(m, c, true); intrs = j } for (var h = 0; h < intrs.length; h++) { var w = intrs[h], o = this._getAngle(w), p = a.rotatePointAt(x, r, o, e, g), q = a.rotatePointAt(y, z, o, e, g), d = new k(p.x, p.y, q.x, q.y); d.strokeStyle = c.strokeStyle; d.lineWidth = c.lineWidth; d.strokeDashArray = c.strokeDashArray; d.zIndex = c.zIndex; d.dontRound = true; n.push(d) } return n } It looks like we are eliminating at least the NewArray node depicted above.

Created attachment 193931 [details] Patch Reviewed in person.

Committed r146268: <http://trac.webkit.org/changeset/146268>

Thanks for the fast fix! The fix however seems to be very specific to the new improvements in DFG, so before I try myself to backport it to something that fits december/january DFG, I would like to ask if you plan to backport it to the safari-536.30-branch because that might also be useable as a backported fix to Qt?

Do we have a layout test for this?

(In reply to comment #9) > Do we have a layout test for this? Working on one.

(In reply to comment #8) > Thanks for the fast fix! > > The fix however seems to be very specific to the new improvements in DFG, so before I try myself to backport it to something that fits december/january DFG, I would like to ask if you plan to backport it to the safari-536.30-branch because that might also be useable as a backported fix to Qt? You are likely referring to the Node* improvements made in http://trac.webkit.org/changeset/141069. I don't have plans to back port.

(In reply to comment #11) > (In reply to comment #8) > > Thanks for the fast fix! > > > > The fix however seems to be very specific to the new improvements in DFG, so before I try myself to backport it to something that fits december/january DFG, I would like to ask if you plan to backport it to the safari-536.30-branch because that might also be useable as a backported fix to Qt? > > You are likely referring to the Node* improvements made in http://trac.webkit.org/changeset/141069. I don't have plans to back port. No, I was just naively observing the files and methods you modified are relatively recent additions. Are you sure this is not a potential security issue that would need to be backported?

(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #8) > > > Thanks for the fast fix! > > > > > > The fix however seems to be very specific to the new improvements in DFG, so before I try myself to backport it to something that fits december/january DFG, I would like to ask if you plan to backport it to the safari-536.30-branch because that might also be useable as a backported fix to Qt? > > > > You are likely referring to the Node* improvements made in http://trac.webkit.org/changeset/141069. I don't have plans to back port. > > No, I was just naively observing the files and methods you modified are relatively recent additions. Are you sure this is not a potential security issue that would need to be backported? The underlying bug fixed here was introduced in http://trac.webkit.org/changeset/144862.

(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #8) > > > > Thanks for the fast fix! > > > > > > > > The fix however seems to be very specific to the new improvements in DFG, so before I try myself to backport it to something that fits december/january DFG, I would like to ask if you plan to backport it to the safari-536.30-branch because that might also be useable as a backported fix to Qt? > > > > > > You are likely referring to the Node* improvements made in http://trac.webkit.org/changeset/141069. I don't have plans to back port. > > > > No, I was just naively observing the files and methods you modified are relatively recent additions. Are you sure this is not a potential security issue that would need to be backported? > > The underlying bug fixed here was introduced in http://trac.webkit.org/changeset/144862. Ah, then there is/was a second issue. The original crash that opened this bug happens in Qt 5.0.1 which was branched from WebKit trunk in December.