PhantomJS immediately crashing after launch through Karma #903
Comments
|
the same issue here |
|
I'm running into this issue as well, using build 14965. It is one of very few remaining issues that prevent me from switching to Windows on my job. I'm not very experienced with Then again, this might be a trace of the process that crashes because PhantomJS has crashed. Anyway, it's my best effort to hopefully drive this issue forward. |
|
Following up on my own trace, my guess ist that |
|
The same issue here I am using build 14986. PhantomJS is working fine for both localhost and external hosts, but as soon as i point it to my karma webserver it crashes. It could be related to the use of websockets, because karma uses socket.io
|
|
To save folks a click-through: The underlying issue is WSL's lack of support for |
|
Thanks @aseering for chiming in. |
|
@moanrose I don't get how this is related to a socket flag used by keystoneauth. Seems random to me. I certainly don't see any use of @sunilmut I'd be happy if a fix was inbound, but I'm not convinced |
|
@lephyrus You are right, i have no empiric evidence whatsoever for my thesis. it was merely a suggestion. I stubled upon a issue about WSL & websockets, and i assumed it was related. |
|
@lephyrus - |
|
@sunilmut Thanks for the explanation - I didn't even realize that is the return value... 🙄 If you could take a look, that would be great. Reproduction steps (assuming installed NodeJS):
Expected output: Actual output: |
|
how long until the fix is in the insider build and how long until it's in a normal update? |
|
|
|
@bmayen test it |
|
No it is not
|
|
@moanrose - thanks for trying it out. Can you share more details? Such as, which build did you try it on? And, repro steps? Preferably, also, a strace of the failing command. |
|
I'll try to find some time today or tomorrow over my lunch break to kick the tires and report back |
|
I'm not on 15002, but I've already provider (very simple) repro steps (#903 (comment)) and strace output (#903 (comment)). If that's not good enough, please be more specific. |
|
@sunilmut, any progress on this? This bug is one of the main reasons I still have to keep a VM running :) |
|
Hi all, just wanted to ping on this thread as well. The latests Windows 10 builds seem to have fixed a good number of issues in socket-related system calls, which have let me run most of my NodeJS web app on Windows bash. Except for my client-side unit tests based on PhantomJS, which seem to depend on this issue. Since I don't see much activity on here, I was wondering what the state is. Thanks all! |
|
Hi @rafaelubal -- I think the status is that we're waiting on someone who's experiencing this bug to reply to @sunilmut 's request here for an strace. |
|
I think there is enough information here for a repro. Just needs to be looked at and triaged. |
|
so Creators Update was released but this problem persists, i can't run karma-phantomjs ! any ideas to fix this? |
|
@sebdelvalle -- that's a good question, but I think the answer is the same as it was yesterday :-) See the previous few posts. Creators has actually been out for a.while now via Insider builds, which a bunch of us here are using. If someone does come up with a workaround, it would be great if they posted it here. |
|
Sorry for the thread spam (I spent so long editing that first reply!), but here's proof of my In one tmux pane: In another tmux pane: |
I did not. I should have paid closer attention to all your steps. [I was just doing a quick look-see.]
That's good progress. And your pselect6 theory sounds entirely plausible. If you can do a repro test case that will certainly earn a gold star. |
|
I've managed to build a debug PhantomJS 2.1.1 binary and reproduce the crash. I've added a new GDB Logs section to my demo README, included below for easy reference. I'll try tracing through the code some more over the next few days to see if any other insights emerge. GDB logs from a debug build of the PhantomJS 2.1.1 binary are in the
the second,
|
|
Yet more: I've collected stack traces from
Top of the Top of the stack trace from the crash: |
|
Musing some more on the fact the following appears in logs/Ubuntu-17.04-debug/strace.log, and not in the crashing WSL log: I did a quick search for "WSL EINPROGRESS" and found #1584. Of particular interest is the comment that all
Indeed, our WebSockets appear to be nonblocking: Will dig deeper on the suspicion that the lack of |
|
OK, pretty sure I nailed it: it is the lack of nonblocking At this point I'm reasonably certain that the failure is due to the present lack of support for nonblocking Compare the system calls from to those from We'll piece together three related stack traces from The paths to QT source files that follow are relative to the root of the PhantomJS repo at tag d->_q_startConnecting(info);The stack trace for the WSL int socket = qt_safe_socket(protocol, type, 0, O_NONBLOCK);The stack trace for the WSL // Tries to connect to the address. If it succeeds immediately
// (localhost address on BSD or any UDP connect), emit
// connected() and return.
if (socketEngine->connectToHost(host, port)) {
//_q_testConnection();
fetchConnectionParameters();
return;
}This int connectResult = qt_safe_connect(socketDescriptor, sockAddrPtr, sockAddrSize);
#if defined (QNATIVESOCKETENGINE_DEBUG)
int ecopy = errno;
#endif
if (connectResult == -1) {
switch (errno) {
// ...snip ...
case EINPROGRESS:
case EALREADY:
setError(QAbstractSocket::UnfinishedSocketOperationError,
InvalidSocketErrorString);
socketState = QAbstractSocket::ConnectingState;
break;
// ...snip...
default:
break;
}
if (socketState != QAbstractSocket::ConnectedState) {
// ...snip...
return false;
}
}
// ...snip...
socketState = QAbstractSocket::ConnectedState;
return true;If the underlying // Tries to connect to the address. If it succeeds immediately
// (localhost address on BSD or any UDP connect), emit
// connected() and return.
if (socketEngine->connectToHost(host, port)) {
//_q_testConnection();
fetchConnectionParameters();
return;
}This in turn produces our final stack trace: The assertion in void WebSocketChannel::didOpenSocketStream(SocketStreamHandle* handle)
{
LOG(Network, "WebSocketChannel %p didOpenSocketStream()", this);
ASSERT(handle == m_handle);which under further inspection in GDB reveals: |
|
@mbland (and @therealkenc) great debugging and details. Thanks for digging to the bottom of this. Yes, |
|
Amazing work everybody! |
|
Good to find this. It's the first blocker I've run into in about 2 months since switching to using WSL for dev full time. I mean, aside from vi being broken |
|
Just an update that |
|
@sunilmut any update on this? Looks like the Fall Creators Update is due to land a week from today. Is the fix for this issue ready? |
|
@Bradleycorn - As Sunil said above, this fix will be in Fall Creator's Update. |
|
Awesome thanks @benhillis. The "also" in @sunilmut's comment threw me off. I was thinking a specific fix for this might have been released on it's own. I'll watch for the Creators Update. |
|
I have the Fall Creators Update, and I'm still seeing this issue ... @benhillis @sunilmut anything we need to do to get |
|
@Bradleycorn Are you sure you've still got the issue, or that you've actually got the FCU installed? Here's what I see in my WSL environment after installing the FCU (not sure what it was before): The reason I ask is becuase I'm happy to report that this is what I see running in my mbland/custom-links project at commit 2fa5a50 (after having to do an explicit Perhaps @sunilmut and @benhillis may want others to confirm as well, but from my perspective, this and #1584 can be closed. :-) |
|
@Bradleycorn - Could you share the output of the |
|
@mbland - Thanks for the validation. This issue should be resolved. Once @Bradleycorn issue is resolved, I will close this out. |
Please use the following bug reporting template to help produce actionable and reproducible issues:
PhantomJS seems to be able to be launched standalone, but cannot be used with Karma. This issue has also been posted to the karma-phantomjs-launcher issues page with no workaround found. karma-runner/karma-phantomjs-launcher#124
I'm using a workaround to get past #468 since Webpack requires os.interfaces. Part of me wonders if this could be the cause.
Headless execution of tests with PhantomJS
`> NODE_ENV=test ./node_modules/karma/bin/karma start karma.conf.js
Info: No mac address - uniqid() falls back to uniqid.process(). no interfaces found
15 08 2016 17:30:27.960:INFO [karma]: Karma v1.2.0 server started at http://localhost:9876/
15 08 2016 17:30:27.963:INFO [launcher]: Launching browser PhantomJS with unlimited concurrency
15 08 2016 17:30:27.977:INFO [launcher]: Starting browser PhantomJS
15 08 2016 17:30:29.554:ERROR [phantomjs.launcher]: PhantomJS has crashed. Please read the bug reporting guide at
http://phantomjs.org/bug-reporting.html and file a bug report.
15 08 2016 17:30:29.556:ERROR [launcher]: Cannot start PhantomJS
15 08 2016 17:30:29.563:INFO [launcher]: Trying to start PhantomJS again (1/2).
15 08 2016 17:30:30.035:ERROR [phantomjs.launcher]: PhantomJS has crashed. Please read the bug reporting guide at
http://phantomjs.org/bug-reporting.html and file a bug report.
15 08 2016 17:30:30.036:ERROR [launcher]: Cannot start PhantomJS
15 08 2016 17:30:30.039:INFO [launcher]: Trying to start PhantomJS again (2/2).
15 08 2016 17:30:30.507:ERROR [phantomjs.launcher]: PhantomJS has crashed. Please read the bug reporting guide at
http://phantomjs.org/bug-reporting.html and file a bug report.
15 08 2016 17:30:30.508:ERROR [launcher]: Cannot start PhantomJS
15 08 2016 17:30:30.511:ERROR [launcher]: PhantomJS failed 2 times (cannot start). Giving up.`
Anniversary Update
Run Karma with PhantomJS
I can't figure out how to get a strace on this, but if someone knows how to I'll get it up.
Webpack, Karma, PhantomJS-prebuilt through npm, karma-webpack, karma-phantomjs-launcher is I think all needed to reproduce. The use case for this project is using Chai and Mocha.
The text was updated successfully, but these errors were encountered: