I get this error when running a number of tests in seleniums Bromine, The selenium RC version 1.0.2 outputs this:
WARN - GET /selenium-server/driver/?cmd=testComplete&1=&2=&sessionId=1274d41621c64fc08c1e7ea0a58f260b HTTP/1.0 java.lang.IllegalStateException: unexpected command json={command:"open",target:"/Library/Security/Login.aspx?ReturnUrl=%2fIndex.aspx",value:""} in place before new command selectWindow could be added at org.openqa.selenium.server.CommandQueue.doCommandWithoutWaitingForARe
sponse(CommandQueue.java:121)
Any ideas
Recently I had to track this problem on our testing environment and it appears, that the reason was Firefox crashing. If this error follows two 'Command timed out' exceptions, then your browser probably crashed or hanged.
Upon inspection of code of Selenium RC I realized that 'Unexpected command' error appears when there is an overflow in command queue. This can be caused by lack of responses from the browser, so if browser crashes, you end up receiving this error.
Check your dmesg logs (or some other logs, if not under Linux) to see, if there is anything suspicious. In my case there were entries like this:
plugin-containe[30867]: segfault at 0 ip 00007f07a6ff503d sp 00007f079d593260 error 4 in libxul.so[7f07a6265000+146f000]
libxul.so and plugin-container are modules of Firefox. Upgrading it to newer version helped in my case.
I'm also seeing this IllegalStateException, much too frequently. Its occurrence seems random, as if something in Selenium isn't synchronized properly. I have seen it several times in connection with a TestNG Listener that calls selenium to do a screen capture, but again, it's unpredictable.
Related
I’m executing automatic tests using Katalon in console mode.
Sometimes job executed by Jenkins ends unexpectedly without any error.
Katalon Studio version 5.10.1,
Jenkins version 2.121.3
I've tried to find some Jenkins logs other than console logs, which logged why that job is aborted
Jenkins console logs:
/var/lib/jenkins/.katalon/5.10.1/Katalon_Studio_Linux_64-5.10.1/katalon -noSplash -runMode=console -projectPath=/var/lib/jenkins/workspace/(...) -browserType=Firefox -testSuitePath=Test Suites/MainTestingSuite
Delete folder: Libs
Opening project file: /var/lib/jenkins/workspace/(...).prj
Request sent successfully.
[EL Warning]: 2019-05-10 13:54:15.046–Ignoring attribute [lastRun] on class [TestSuiteEntity] as no Property was generated for it.
**Build step ‘Execute shell’ changed build result to UNSTABLE**
Got SIGTERM, exiting
In exit
Terminating xvnc.
$ vncserver -kill :80
Killing Xvnc4 process ID 29224
Archiving artifacts
‘Reports/MainTestingSuite/’ doesn’t match anything, but ‘’ does. Perhaps that’s what you mean?
No artifacts found that match the file pattern “Reports/MainTestingSuite/”. Configuration error?
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?
Finished: FAILURE
Someone already had that problem? How to track that case?
I’m waiting for your answer.
I’ve finally found cause of that problem.
Katalon job failed like that, when you try executed two Katalon instances at the moment. I’ve changed number of executors at jenkins to 1, and problem is not occuring anymore.
Best Regards
When using the APIs defined by Protractor & Jasmine (the default/supported runner for Protractor), the tests will always work okay on individual developer laptops. For some reason when the test runs on the Jenkins CI server, they will fail (despite being in the same docker containers on both hosts, and that was wildly frustrating.)
This error occurs: A Jasmine spec timed out. Resetting the WebDriver Control Flow.
This error also appears: Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
Setting getPageTimeout & allScriptsTimeout to 30 seconds had no effect on this.
I tried changing jasmine.DEFAULT_TIMEOUT_INTERVAL to 60 seconds for all tests in this suite, once the first error appears then every test will wait the full 60 seconds and time out.
I've read and reread Protractor's page on timeouts but none of that seems relevant to this situation.
Even stranger still, it seems like some kind of buffer issue - at first the tests would always fail on a particular spec, and nothing about that spec looked wrong. While debugging I upgraded the selenium docker container from 2.53.1-beryllium to 3.4.0-einsteinium and the tests still failed but they failed a couple specs down - suggesting that maybe there was some optimization in the update and so it was able to get more done before it gave out.
I confirmed that by rearranging the order of the specs - the specs that had failed consistently before were now passing and a test that previously passed began to fail (but around the same time in the test duration as the other failures before the reorder.)
Environment:
protractor - 5.1.2
selenium/standalone-chrome-debug - 3.4.0-einsteinium
docker - 1.12.5
The solution ended up being simple - I first found it on a chrome bug report, and it turned out it was also listed right on the front page of the docker-selenium repo but the text wasn't clear as to what it was for when I'd read it the first time. (It says that selenium will crash without it, but the errors I was getting from Jasmine were just talking about timeouts, and that was quite misleading.)
Chrome apparently utilizes /dev/shm, and apparently that's fairly small in docker. There are workarounds for chrome and firefox linked from their README that explain how to resolve the issue.
I had a couple test suites fail after applying the fix but all the test suites have been running and passing for the last day, so I think that was actually the problem and that this solution works. Hope this helps!
I'm doing this:
zef install Selenium::WebDriver
And I'm getting it stuck at:
===> Searching for: Selenium::WebDriver
===> Testing: Selenium::WebDriver:ver('0.0.1')
Cannot obtain a session after 10 attempts
in submethod BUILD at /home/user123/.zef/store/perl6-selenium-webdriver.git/5e3ff320d2f392e44df1433f0544201c154f2590/lib/Selenium/WebDriver/Wire.pm6 (Selenium::WebDriver::Wire) line 66
in block <unit> at t/05-firefox.t line 45
# Looks like you planned 91 tests, but ran 1
JavaScript error: , line 0: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIAppStartup.trackStartupCrashEnd]
My OS -- arch linux -- is up to date.
Summary
Like all Perl 5 or Perl 6 packages, the Selenium::WebDriver package includes a suite of tests that check that it appears to work properly on your system.1 This test suite gets run at the end of installation, i.e. the installer downloads the package, runs its builder code and only then runs its test suite. If there's an error, then (by default2) the installer displays error information and exits immediately. That's what it's done in your case.
The current Selenium::WebDriver package was successfully installing 2 months ago complete with the message showing success on an Ubuntu for the same test that is a fail on your system. Then again, a search of the #perl6 logs for 'selenium' suggests that there may be an intermittent error with one of the modules that Selenium::WebDriver uses; this may indeed be the root of the problem.
The README of the repo for Selenium::WebDriver begins with a link to a document that says the protocol it describes is "obsolete". The most recent item in the issue queue of the Selenium::WebDriver repo is titled "Add support for Firefox Marionette WebDriver". Please consider adding a comment to that issue pointing to this SO question if you think it's relevant.
If you look at the error messages you'll see a Firefox test failed. One possibility is that there's an error in Firefox, or some related software, beyond official latest arch linux.
Some plausibly simple responses to the Firefox error message:
Try manually loading Firefox before trying to install the Perl 6 package. Does that fix the problem?
I don't know what options you have for making the Selenium::WebDriver package not see your Firefox other than completely uninstalling it, but maybe you can do that? Then try installing again (and the package will presumably then test/use, say, Chrome instead of Firefox).
If that doesn't work, consider posting a new Selenium::WebDriver repo issue (and link to this SO question).
The top level error message is "Cannot obtain a session after 10 attempts". It's generated by line 66 of the package's lib/Selenium/WebDriver/Wire.pm6 file. I don't think that line helps much in this case but imo it's always worth taking at least a quick glance at the source code corresponding to error messages.
Looking at the next level down we see the error comes from "t/05-firefox.t line 45" which is my $driver = Selenium::WebDriver::Firefox.new;. It looks like it's trying to connect to Firefox and failing. Looking further up in that test script one can see that it thinks it found Firefox on your system (because the code block in unless which('firefox') { ... } clearly didn't trigger).
The deepest part of the error information shows that a "Javascript error" has been encountered, something to do with nsIAppStartup.trackStartupCrashEnd.
Often a problem is specific to the versions of software involved. The Selenium::WebDriver package version is clearly 0.0.1 but it would be nice to see the version info from the other main pieces involved including your Perl 6 compiler (perl 6 -V iirc), the installer (zef -V iirc), and your OS and Firefox. In this particular case I'm pretty sure the problem is not in your Perl 6 compiler (Rakudo) nor in the installer (zef) but I might be wrong and I still recommend you always consider including generous version info when you post your first version of a question.
1 The test suite for the Selenium::WebDriver package work as per Perl 6 testing guidelines in general and per the Testing section of the Selenium::WebDriver's repo README in particular.
2 You can usually force Perl installers to continue regardless if you know an error doesn't matter in your case. I think it's -force-test to force zef to continue testing rather than stop after the first error and -force-install to complete the install despite errors.
I'm getting a Chrome Driver related error when running my Selenium tests. The error message is "Unable to Discover Open Pages." The Selenium tests were all running fine until last evening. The problem seemed to begin after a reboot of the server the day before. I cannot reproduce this error on my local box. Running the Selenium tests from the command line on the server does open the Chrome Browser but results in the same error. Any ideas?
Line that is failing:
chromeDriver = new OpenQA.Selenium.Chrome.ChromeDriver(externalDriverPath);
Error message and stacktrace:
unable to discover open pages (Driver info:
chromedriver=2.1,platform=Windows NT 6.1 SP1 x86_64) at
OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response
errorResponse) at
OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String
driverCommandToExecute, Dictionary`2 parameters) at
OpenQA.Selenium.Remote.RemoteWebDriver.StartSession(ICapabilities
desiredCapabilities) at
OpenQA.Selenium.Remote.RemoteWebDriver..ctor(ICommandExecutor
commandExecutor, ICapabilities desiredCapabilities) at
OpenQA.Selenium.Chrome.ChromeDriver..ctor(String
chromeDriverDirectory, ChromeOptions options) at
OpenQA.Selenium.Chrome.ChromeDriver..ctor(String
chromeDriverDirectory) at SeleniumTests.BaseTest.SetupBrowsers()
When creating an instance of the ChromeDriver, a console window appears. The server with the error seems to refer to things NOT IMPLEMENTED.
ChomeDriver Output From the Server with the Error:
Started ChromeDriver (v2.1) on port 2984
[4700:4292:0108/111503:ERROR:gpu_info_collector_win.cc(102)] Can't
retrieve a va lid WinSAT assessment.
[4700:4292:0108/111503:ERROR:chrome_views_delegate.cc(176)] NOT
IMPLEMENTED
[4700:4292:0108/111503:ERROR:desktop_root_window_host_win.cc(746)] NOT
IMPLEMENT ED [0108/111504:ERROR:gl_surface_egl.cc(132)] eglInitialize
failed with error UNKNO WN [0108/111504:ERROR:gl_surface_win.cc(97)]
GLSurfaceEGL::InitializeOneOff failed.
ChomeDriver Output From My PC which works fine:
Started ChromeDriver (v2.1) on port 18786
[884540:883760:0108/114010:ERROR:gpu_info_collector_win.cc(102)] Can't
retrieve a valid WinSAT assessment.
[884992:884996:0108/114010:ERROR:base_feature_provider.cc(122)]
manifestTypes: A llowing web_page contexts requires supplying a value
for matches.
[885232:885236:0108/114011:ERROR:base_feature_provider.cc(122)]
manifestTypes: A llowing web_page contexts requires supplying a value
for matches.
[884540:883760:0108/114011:ERROR:base_feature_provider.cc(122)]
manifestTypes: A llowing web_page contexts requires supplying a value
for matches. [0108/114011:ERROR:gl_surface_egl.cc(131)] eglInitialize
failed with error UNKNO WN [0108/114011:ERROR:gl_surface_win.cc(54)]
GLSurfaceEGL::InitializeOneOff failed.
You are using a highly outdated version of the ChromeDriver. Your first port of call should be to update it here.
I would highly suspect the problem is your Chrome on your server has updated, and ChromeDriver v2.1 doesn't support any recent versions of Chrome.
Look here for other possible solutions: https://groups.google.com/forum/?hl=en#!topic/selenium-users/gfvfH-YEC48
In my case, adding the --no-sandbox argument to ChromeOptions solved the problem.
Here's a quick workaround I found while digging around to get rid of that error: unknown error: unable to discover open pages
In your protractor config file, add the following:
capabilities: {
browserName: 'chrome',
chromeOptions: {
args: ['--no-sandbox']
}
},
The most important line there is the --no-sandbox; adding that line somehow gets rid of that error.
I am not exactly sure why it works but it's a workaround I found while digging around online.
***********************************UPDATES as of 10/04/2016***********************************
Please ignore this part right above as that workaround is NOT a proper fix; below I show you the actual fix to your problem; you just have an outdated chrome driver and running "webdriver-manager update" will only update up to v2.22 so I'll show you how to grab v2.24 right below.
Read on if your webdriver-manager update doesn't update chromedriver
to the latest i.e past v2.22 OR to v2.24 as of 10/04/2016.
I lost a few weeks pulling my hair around an issue I had with "Unable to discover open pages" and every time I would update the chromedriver, it would update to version 2.22 for chromedriver and I believe the selenium server to v2.53.
My problem wasn't really with the selenium server so v2.53 was fine.
Issue was with chromedriver v2.22.
Eventhough this chromdriver link showed that there was a latest version of 2.24, 'webdriver-manager update' would NOT pick up that latest version, it would only grab version 2.22 of the chrome driver.
How did I go around this?
Simply run the command below after you check this link for which version of chromedriver you want to update to; for instance, I wanted v2.24 so I ran the command below:
webdriver-manager update --versions.chrome 2.24
If you check your location: C:\Users\<USER>\AppData\Roaming\npm\node_modules\webdriver-manager\selenium\
You should see that the desired chromedriver was downloaded there; if it's not there, read the command prompt logs and it'll tell you where it downloaded your chromdriver files.
Hope that helps someone!
I had the same problem, but updating to the latest ChromeDriver (v2.8) did not solve it for me. I was running Selenium on a CI server (A Dell machine running 64 bit Win 7). I got the exception every time when the server had been 'idle' for a while.
What fixed the problem for me was to set 'Turn off display after' in Windows' Power Options to 'Never'.
I am running selenium with python in Docker on a Google compute instance. For me, the issue was that my instance didn't have enough memory, and my scrape job would fail with this error. Upgrading it to g1-small resolved the issue for me.
In my case the problem was due to one of my colleagues, who started his tests at the same time on the same server, so that my web driver could not access the Chrome executable. It also happens if someone didn't finish his web driver process properly, in this case you have to kill it manually.
First make sure you have updated you chrome browser, through the Menu UI.
Then update ChromeDriver, here.
For some reason the Chrome driver cannot interpret https traffic. If you change your link to http it will work nicely.
I'm trying to follow the tutorial here to setup a headless selenium test-run with jenkins. I'm running CentOS 5.6, and I've followed the instructions. Now, when I run this:
export DISPLAY=":99" && java -jar /var/lib/selenium/selenium-server.jar -browserSessionReuse -htmlSuite *firefox http://www.google.com ./test/selenium/html/TestSuite.html ./target/selenium/html/TestSuiteResults.html
Selenium hangs on INFO - Checking Resource Aliases. I can run the TestSuite.html file manually, and the path is correct.
How can I even begin to try and figure out what's going on? Is there a way I could connect to the display to see what's happening? I am behind a corporate proxy, but with or without -Dhttp.proxyHost arguments, I get the same hung result.
Well, after pointing at an internal server, I get right on past the INFO - Checking Resource Aliases step, so clearly the proxy was the issue.
By trying to hit a site that required the proxy, I was doing too much at once. Confounding variables confounded me.
Selenium is not hanging on INFO - Checking Resource Aliases. Its waiting for a command to execute. You need to trigger your tests using ANT or some other build tool in Jenkins. That should get you going