Crash when running ember tests

[winding-lines]

We are getting a crash in PhantomJS 2.0 on Linux only, OS X works fine. When running in the debugger I get the following stack trace. Do you have any feedback on how to make progress?

Program received signal SIGSEGV, Segmentation fault.
JSC::DFG::prepareOSREntry (exec=0x7fff8fc27e78, codeBlock=0x7fff726fd000, bytecodeIndex=) at dfg/DFGOSREntry.cpp:121
121 if (!entry->m_expectedValues.local(local).validate(exec->registers()[local].jsValue())) {
Missing separate debuginfos, use: debuginfo-install expat-2.0.1-11.el6_2.x86_64 fontconfig-2.8.0-3.el6.x86_64 freetype-2.3.11-14.el6_3.1.x86_64 glibc-2.12-1.149.el6_6.5.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.2.x86_64 libcom_err-1.41.12-14.el6.x86_64 libgcc-4.4.7-3.el6.x86_64 libicu-4.2.1-9.1.el6_2.x86_64 libjpeg-turbo-1.2.1-1.el6.x86_64 libpng-1.2.49-1.el6_2.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-3.el6.x86_64 openssl-1.0.1e-30.el6_6.2.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) where
#0 JSC::DFG::prepareOSREntry (exec=0x7fff8fc27e78, codeBlock=0x7fff726fd000, bytecodeIndex=) at dfg/DFGOSREntry.cpp:121
#1 0x0000000001850aaa in JSC::cti_optimize (args=0x7fffffffc100) at jit/JITStubs.cpp:2061
#2 0x00007fffb20d8568 in ?? ()
#3 0x00007fff770eb570 in ?? ()
#4 0x0000000000000000 in ?? ()

[winding-lines]

I was looking at the history of the DFGOSREntry file to see if there is a change we could cherry pick. The file changed a lot a couple of revisions after the one we have. Would it be possible to upgrade to a newer Webkit revision? I am not sure what amount of work would be required.

[zackw]

We probably wouldn't try to fix something like this except by upgrading Webkit.

That said, it would be really helpful if you could come up with a minimized test case. Ideally that's an entirely self-contained .js file that, when run (phantomjs testcase.js) demonstrates the same crash. Since this appears to be a crash inside the JavaScript interpreter, that shouldn't be that hard. If you need to load webpages in order to provoke the bug, you can do that with the "webserver" module.

[winding-lines]

Zack,

We have been trying to isolate, no success yet. What is the process for upgrading webkit? I have some cycles...

Marius

On Aug 6, 2015, at 7:43 AM, Zack Weinberg notifications@github.com wrote:

We probably wouldn't try to fix something like this except by upgrading Webkit.

That said, it would be really helpful if you could come up with a minimized test case. Ideally that's an entirely self-contained .js file that, when run (phantomjs testcase.js) demonstrates the same crash. Since this appears to be a crash inside the JavaScript interpreter, that shouldn't be that hard. If you need to load webpages in order to provoke the bug, you can do that with the "webserver" module.

—
Reply to this email directly or view it on GitHub.

[zackw]

I haven't worked on Webkit upgrades myself; I'm just fielding bug reports. @vitallium or @ariya may be able to explain what's involved.

[vitallium]

Short version:
Our upgrade process looks like this:

• download a vanilla version of QtWebkit
• apply our patches (for evaluateJavaScript, printing support, etc)
• test all the things
• do the usual Github merge process.

But this was before Qt decided to drop support for QtWebkit. The latest and final release of QtWebkit is 5.5. We will migrate to it eventually.
QtWebkit always was behind in functionality in comparison with nightly Webkit. This leads to outdated stuff.
Webkit already removed all Qt related things from the source tree. So we can't just take and use the latest Webkit. There are a lot of things changed.

[ariya]

@winding-lines Can you quickly try it again with PhantomJS 2.1?

[stale]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!