I'm running E2E tests using Protractor/Jasmine. Using VS Code to author.
I had no issue when running these tests/frameworks when running on Win7 but since "upgrading" to Win10, I'm getting errors:
PS E:\Projects\DBM_TAGS> protractor dbm-tags.js
[12:01:31] I/launcher - Running 1 instances of WebDriver
[12:01:31] I/local - Starting selenium standalone server...
[12:01:31] W/launcher - Ignoring uncaught error Error: spawn C:\Program
Files\Java\jdk-13.0.2\bin\bin\java ENOENT
[12:02:02] E/launcher - Error: Error: Timed out waiting for the WebDriver server at
http://192.168.1.241:51064/wd/hub
at onError (C:\Users\david\AppData\Roaming\npm\node_modules\selenium-
webdriver\http\util.js:102:16)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
[12:02:02] E/launcher - Process exited with error code 100
I've never seen the machine's IP shown before...normally it's http://localhost:4444/wd/hub....port 4444 is what's showing when Webdriver-manager starts up.
So apart from the OS nothing has changed...any ideas please?
Further to #yong's comments below...the server IS starting but the error message appears to indicate that protractor cannot connect to it.
Here's the Webdriver manager's startup log..
PS E:\Projects\DBM_TAGS> webdriver-manager start
webdriver-manager: using local installed version 12.1.7
[14:35:39] I/start - java -
Dwebdriver.gecko.driver=E:\Projects\DBM_TAGS\node_modules\webdriver-
manager\selenium\geckodriver-v0.26.0.exe -
Dwebdriver.chrome.driver=E:\Projects\DBM_TAGS\node_modules\webdriver-
manager\selenium\chromedriver_80.0.3987.16.exe -jar
E:\Projects\DBM_TAGS\node_modules\webdriver-manager\selenium\selenium-server-
standalone-3.141.59.jar -port 4444
[14:35:39] I/start - seleniumProcess.pid: 10956
14:35:42.662 INFO [GridLauncherV3.parse] - Selenium server version: 3.141.59, revision: e82be7d358
14:35:43.030 INFO [GridLauncherV3.lambda$buildLaunchers$3] - Launching a
standalone Selenium Server on port 4444
2020-02-09 14:35:43.460:INFO::main: Logging initialized #3439ms to
org.seleniumhq.jetty9.util.log.StdErrLog
14:35:44.358 INFO [WebDriverServlet.<init>] - Initialising WebDriverServlet
14:35:45.306 INFO [SeleniumServer.boot] - Selenium Server is up and running on
port 4444
So surely listening is happening on port 4444 and not Port 51064 as per the error. NB: everytime you try to run the tests, a different port number is reported.
http://192.168.1.241:51064/wd/hub is the webdriver start an api server on. If you use chrome, chromedriver.exe will start and expose a url like it. The api server accept commands from test script, like click, input. Then convert these commands to directives which chromedriver.exe understand how to manipulate browser.
you can run the chromedriver.exe directly from cmd window to see it can start or not.
Related
I am stuck in this problem. I am running cypress tests. When I run locally, it runs smoothly. when I run in circleCI, it throws error after some execution.
Here is what i am getting:
[334:1020/170552.614728:ERROR:bus.cc(392)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[334:1020/170552.616006:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[334:1020/170552.616185:ERROR:bus.cc(392)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[521:1020/170552.652819:ERROR:gpu_init.cc(441)] Passthrough is not supported, GL is swiftshader
Current behavior:
When I run my specs headless on the circleCI, Cypress closed unexpectedly with a socket error.
Error message:
The Test Runner unexpectedly exited via a exit event with signal
SIGSEGV
Please search Cypress documentation for possible solutions:
https://on.cypress.io
Platform: linux (Debian - 10.5)
Cypress Version: 8.6.0
Issue resolved by reverting back cypress version to 7.6.0.
I had this same issue on within our Azure builds as well. We only recently migrated from Cypress 8.4.0. Going back to that has solved the problem.
downgrade the cypress by running npm install cypress#7.6.0
Downgrade of cypress to 8.3.0 worked for me to solve that, you dont need to go to previous versions.
npm install cypress#8.3.0
SIGSEGV means a segmentation fault error. Read all about it here.
"In practice, a segfault occurs when your program breaks some
fundamental rule set by the operating system. In that case, the
operating system sends your process a signal (SIGSEGV on Mac & Linux,
STATUS_ACCESS_VIOLATION on Windows), and typically the process shuts
down immediately."
This blog post also goes into detail about how this can occur, even if you don't directly interact with the operating system (since we're writing JavaScript). Please read it on the original author's site for context.
But in short - you are likely encountering this error because
a. you upgraded Cypress while on an old version of NodeJS, or
b. you upgraded NodeJS, while you have Cypress code that is directly or indirectly incompatible (this could be your own code, or one of its dependencies) with that NodeJS version
Since SIGSEGV is a complete shutdown, you have no stack trace or debug information to guide you. So you have to debug the old fashioned way, turning tests and/or dependencies on or off to locate the problem in your code.
I have created a new react native project by running "react-native init MyFirstProject". I have also installed node and have added no code of my own to any of the files.
I have tried to run the project to make sure it works by running "react-native run-ios --simulator="iPhone 8"". The command runs successfully but I am given the following error.
Could not connect to development server.
Ensure the following:
Node server is running and available on the same network - run 'npm start' from react-native root
Node server URL is correctly set in AppDelegate
WiFi is enabled and connected to the same network as the Node Server
URL: http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false
RCTFatal
__28-[RCTCxxBridge handleError:]_block_invoke
_dispatch_call_block_and_release
_dispatch_client_callout
_dispatch_main_queue_callback_4CF
CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE
__CFRunLoopRun
CFRunLoopRunSpecific
Blockquote
GSEventRunModal
UIApplicationMain
main
start
How do I fix this error?
Try opening your project ios/MyFirstProject/MyFirstProject.xcworkspace and see if there's any build error.
I ran into this problem too, with the same error:
RCTFatal __28-[RCTCxxBridge handleError:]_block_invoke
It turned out that I had another server running on my local machine on the same port that the expo development client server was running (:8081), and that it was taking priority and then obviously giving the client a very different response to what it was expecting. Quitting the other server fixed the problem.
I tried to install Node.js Setup for the first time (node-v8.9.1-x64 and node-v9.2.0-x64) on a system running Windows 10 64-bit , but it is giving the dreaded error
Node.js Setup Wizard ended Prematurely
Failed Attempts
Launching .msi from Command Prompt ran as Administrator
Disabling the installation options
Performance Counters
Event Tracing
Online Document Shortcuts
Registry Key Search
No registry keys were found when running the following
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{793c9b44-3d6b-4f57-b5d7-4ff80adcf9a2}" /s
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\_V2Providers\{1e2e15d7-3760-470e-8699-b9db5248edd5}" /s
The installation log shows an error status: 1603. [View Installation Log]
Node is not installed
node -v
Output:
'node' is not recognized as an internal or external command, operable program or batch file.
Attempt 3
Tried the following based on Github issue #4329, but theres no output after running this.
msiexec /i node-v8.9.1-x64.msi /qn+ ADDLOCAL=ALL REMOVE=NodePerfCtrSupport,NodeEtwSupport
Any ideas how to solve this problem?
The Example of Dojo tests run under Intern (https://github.com/theintern/intern-examples/tree/master/dojo-example) does not actually test anything, fails on connect to the Sauce network:
$ npm test
> dojo-intern-example#0.1.0 test /home/bogdanbiv/WebstormProjects/intern-examples/dojo-example
> intern-runner config=tests/intern
Listening on 0.0.0.0:9001
Starting tunnel...
Using no proxy for connecting to Sauce Labs REST API.
**********************************************************
A newer version of Sauce Connect (build 1283) is available!
Download it here:
https://saucelabs.com/downloads/sc-4.3-linux.tar.gz
**********************************************************
Started scproxy on port 49172.
Starting secure remote tunnel VM...
Secure remote tunnel VM provisioned.
Tunnel ID: 2f904e21cf1e4c3e83f63a4b3089127c
Secure remote tunnel VM is now: booting
Secure remote tunnel VM is now: running
Remote tunnel host is: maki76020.miso.saucelabs.com
Using no proxy for connecting to tunnel VM.
Establishing secure TLS connection to tunnel...
Cleaning up.
Finished! Deleting tunnel.
Error: failed to connect to tunnel VM.
Error: failed to connect to tunnel VM.
at reject <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:353:17>
at readStartupMessage <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:381:12>
at <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:434:12>
at Array.some <native>
at Socket.<anonymous> <node_modules/intern/node_modules/digdug/SauceLabsTunnel.js:428:21>
at Socket.EventEmitter.emit <events.js:117:20>
at Socket.<anonymous> <_stream_readable.js:746:14>
at Socket.EventEmitter.emit <events.js:92:17>
at emitReadable_ <_stream_readable.js:408:10>
at emitReadable <_stream_readable.js:404:5>
npm ERR! weird error 1
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! not ok code 0
Ok it does complain about having an old Sauce Connect binary, but even after downloading and inserting the path of the newest SC (4.3). I also updated .bin/intern-runner to contain js as a running environment as opposed to the old node command. User and password are the ones from the repository (left them unchanged). I followed the documentation and did uncomment the tunnel in the intern config file.
UPDATE: This problem still occurs. I find it wierd that a proxy is started Started scproxy on port 54687., but, further down, Using no proxy for connecting to tunnel VM.. Aren't these lines supposed to match?
It could be that this mismatch has nothing to do with the original problem? The new Sauce Connect binary is still ignored.
UPDATE: Actually this solution affects only client, local - intern-client config=tests/intern. As a result this solution solves a different problem than the one originally posted. /UPDATE
The problem was that although I executed bower install as documented, the bower components installed in a folder set by the bowerrc global configuration. This was quite different from what the Dojo TodoMVC example required for its components.
Also submitted an issue at https://github.com/theintern/intern-examples/issues/10 and a pull request.
I'm trying to configure Webstorm for using the node.js' debugger.
I've set the enviroment and everything, the app is running fine with the run button, but with the debugger button it just hangs up writing only:
/usr/bin/node --debug-brk=52006 --debug-brk node.js
debugger listening on port 52006
and it doesn't work or writes anything on the output.
Any idea of what is missing? I've already installed node-inspector and everything.
EDIT:
After sometime that I run the code, I get:
Failed to open socket on port 52708, waiting 1000 ms before retrying
Problem solved with the help of JetBrains. In a few words, I used cluster creating child nodes that weren't connected to the debugger.
Full explanation here: https://intellij-support.jetbrains.com/tickets/13630