This seem to happen only for chrome docker nodes. Many other has reported in https://code.google.com/p/chromedriver/issues/detail?id=1097 as well. Don't know if a fix is in the process or not.
status: 13,
state: 'unhandled error',
value:
{ message: 'unknown error: session deleted because of page crash\nfrom tab crashed\n (Session info: chrome=43.0.2357.134)\n (Driver info: chromedriver=2.16.333243 (0bfa1d3575fc1044244f21ddb82bf870944ef961),platform=Linux 4.0.5 x86_64) (WARNING: The server did not provide any stacktrace information)\nCommand duration or timeout: 480 milliseconds\nBuild info: version: \'2.46.0\', revision: \'87c69e2\', time: \'2015-06-04 16:16:47\'\nSystem info: host: \'7c68651c08ea\', ip: \'172.17.0.88\', os.name: \'Linux\', os.arch: \'amd64\', os.version: \'4.0.5\', java.version: \'1.7.0_79\'\nSession ID: 57b9a76e53136441c5fa4459554c6ad0\nDriver info: org.openqa.selenium.chrome.ChromeDriver\nCapabilities [{platform=LINUX, acceptSslCerts=true, javascriptEnabled=true, browserName=chrome, chrome={userDataDir=/tmp/.com.google.Chrome.UfutFO}, rotatable=false, locationContextEnabled=true, mobileEmulationEnabled=false, version=43.0.2357.134, takesHeapSnapshot=true, cssSelectorsEnabled=true, databaseEnabled=false, handlesAlerts=true, browserConnectionEnabled=false, webStorageEnabled=true, nativeEvents=true, hasTouchScreen=false, applicationCacheEnabled=false, takesScreenshot=true}]',
suppressed: [],
localizedMessage: 'unknown error: session deleted because of page crash\nfrom tab crashed\n (Session info: chrome=43.0.2357.134)\n (Driver info: chromedriver=2.16.333243 (0bfa1d3575fc1044244f21ddb82bf870944ef961),platform=Linux 4.0.5 x86_64) (WARNING: The server did not provide any stacktrace information)\nCommand duration or timeout: 480 milliseconds\nBuild info: version: \'2.46.0\', revision: \'87c69e2\', time: \'2015-06-04 16:16:47\'\nSystem info: host: \'7c68651c08ea\', ip: \'172.17.0.88\', os.name: \'Linux\', os.arch: \'amd64\', os.version: \'4.0.5\', java.version: \'1.7.0_79\'\nSession ID: 57b9a76e53136441c5fa4459554c6ad0\nDriver info: org.openqa.selenium.chrome.ChromeDriver\nCapabilities [{platform=LINUX, acceptSslCerts=true, javascriptEnabled=true, browserName=chrome, chrome={userDataDir=/tmp/.com.google.Chrome.UfutFO}, rotatable=false, locationContextEnabled=true, mobileEmulationEnabled=false, version=43.0.2357.134, takesHeapSnapshot=true, cssSelectorsEnabled=true, databaseEnabled=false, handlesAlerts=true, browserConnectionEnabled=false, webStorageEnabled=true, nativeEvents=true, hasTouchScreen=false, applicationCacheEnabled=false, takesScreenshot=true}]',
buildInformation:
{ releaseLabel: '2.46.0',
buildTime: '2015-06-04 16:16:47',
class: 'org.openqa.selenium.internal.BuildInfo',
buildRevision: '87c69e2',
hCode: 323995892 },
cause: null,
supportUrl: null,
systemInformation: 'System info: host: \'7c68651c08ea\', ip: \'172.17.0.88\', os.name: \'Linux\', os.arch: \'amd64\', os.version: \'4.0.5\', java.version: \'1.7.0_79\'',
class: 'org.openqa.selenium.WebDriverException',
additionalInformation: '\nSession ID: 57b9a76e53136441c5fa4459554c6ad0\nDriver info: org.openqa.selenium.chrome.ChromeDriver\nCapabilities [{platform=LINUX, acceptSslCerts=true, javascriptEnabled=true, browserName=chrome, chrome={userDataDir=/tmp/.com.google.Chrome.UfutFO}, rotatable=false, locationContextEnabled=true, mobileEmulationEnabled=false, version=43.0.2357.134, takesHeapSnapshot=true, cssSelectorsEnabled=true, databaseEnabled=false, handlesAlerts=true, browserConnectionEnabled=false, webStorageEnabled=true, nativeEvents=true, hasTouchScreen=false, applicationCacheEnabled=false, takesScreenshot=true}]',
hCode: 1925305384,
screen: null },
class: 'org.openqa.selenium.remote.Response',
hCode: 1527911699 }
Yes... more info here https://github.com/elgalu/docker-selenium/issues/20
But I think this is a bug in Chrome Browser, not in docker seleniums, not in chromedriver because is the browser that crashes.
so is elgalu repository part of the Selenium official one? I know there is already a ticket in yours, but I thought people who worked on the official repository should also know.
elgalu repo is mine, not official. yeah @rubytester is aware, not sure if we can solve this on our end, as I said is Chrome crashing, Firefox does not so maybe Google guys needs some help reproducing the bug to take a look, so far none seem to be involved.
Would be great that someone publish a git repo that recreates this bug consistently by a simple docker run command) and put the link in the chromedriver issue that you posted ;)
I have seen this crashing also on chrome 39 and I wonder if java HeapSize has anything to do with this.
Wild guess, our hub crashed when it's running regular java with default heapsize
seluser@0ceb856ad2df:/$ java -XX:+PrintFlagsFinal -version | grep HeapSize
uintx ErgoHeapSizeLimit = 0 {product}
uintx HeapSizePerGCThread = 87241520 {product}
uintx InitialHeapSize := 95158400 {product}
uintx LargePageHeapSizeThreshold = 134217728 {product}
uintx MaxHeapSize := 1524629504 {product}
However when I start hub with java -Xmx1024m we didn't see hub crashing when having about 60 requests awaiting in the queue. I wonder why this is. (I am not a javatester, I am a rubytester so I don't really understand jvm tweaking).
I'll try running a Chrome node with java -Xmx512m . I am maybe naively assuming this will not eat up too much memory and things won't crash (of course my logic of this may be flawed and I welcome lashings and beatings from the java experts).
and we are also running on OpenJDK. Should we be running on official Oracle runtime?
I'm running with -Xmx6312m and also tried OpenJDK 7, 8 and Oracle jre 8
and can reproduce in all cases; Chrome crashes so maybe it depends on the
UI you're testing.
My case is an angular.js app with many UI based tests including drag and
drop, image resizing and so on. Don't see how this is related to the jvm
but I'm not a Java guy.
On Wed, Jul 29, 2015 at 3:46 AM, rubytester [email protected]
wrote:
and we are also running on OpenJDK. Should we be running on official
Oracle runtime?—
Reply to this email directly or view it on GitHub
https://github.com/SeleniumHQ/docker-selenium/issues/79#issuecomment-125802388
.
Thanks for the field report. We'll try a test today with hub on a VM with Xmx1024m and another VM hosting 4 docker contaieners, each container serving 2 chrome sessions (chrome 39). We have 40 nodes attached to the hub. We'll see how running parallel 100 browser sessions affects this.
Yesterday the hub crashed and by limiting the Xmx1024m it did not and kept session requests in the queue just fine. (NotAJavaGuy(tm))
Tried with exactly Xmx1024m chrome tab crashed consistently, just 1 browser and can see the Aw, Snap! blue window in Chrome :'(
So in my case don't need to overload it to recreate but maybe we are talking about 2 different issues, let's see how the load tests goes :)
Chrome 42 - 44 crashes when manually open http://www.google.com/adwords
Is there issue already opened for Chrome browser in docker. Should I submit a new one for Chromium?
We are running into similar issue with our application same as with http://www.google.com/adwords
We use own docker configuration similar to selenium/node-chrome-debug
Steps to reproduce manually on public selenium image:
docker run -d -p 4444:4444 --name selenium-hub selenium/hub
docker run -it -p 5900:5900 --link selenium-hub:hub selenium/node-chrome-debug
start vnc viewver on default docker IP 127.0.0.1:5900
or for boot2docker IP at 192.168.69.103:5900
(default password is 'secret')
Right mouse click. Open Applications\Terminal Emulators\XTerm
run following commands
sudo su - seluser
google-chrome
In google chrome window type
http://www.google.com/adwords
It loads page and then shows: Aw, Snap!
It is reproducible in all Chrome browsers starting 42 (till latest 44)
Currently on Chrome/44.0.2403.155
It is not reproducible on the our old docker-selenium image with older Chrome/41.0.2272.89
Please refer correct duplicate or let me know where I can submit this issue?
I can provide additional details, logs if needed?
So @issuj figured this out, I just tried below code and Chrome no longer crashes:
Easiest option is sharing shm via docker run ... -v /dev/shm:/dev/shm
Other option is to use the new docker run option --shm-size=1g
Finally you can do it yourself inside the container:
docker run --privilegeddocker exec $id sudo umount /dev/shm
docker exec $id sudo mount -t tmpfs -o rw,nosuid,nodev,noexec,relatime,size=512M tmpfs /dev/shm
However it would be nice to avoid privileged mode.
Other refs:
https://github.com/docker/docker/pull/3505#issue-25240859
https://github.com/docker/docker/pull/4981#issuecomment-56052500
https://github.com/docker/docker/issues/2606#issuecomment-95350288
It also works if use -v /dev/shm:/dev/shm option to share host /dev/shm
In this case you do not need --privileged mode.
Thanks all you guys for poking around and finding the solution. Major win for all.
And thanks @kkochubey1 for the -v /dev/shm:/dev/shm solution. That was the next thing I was thinking about... I'll be glad to test it in my grids setups and I'll report how this works in a larger grid setups
Thank you all for finding the solution. I will close this ticket once my test went through.
If you are using docker-compose add the volume under your Chrome image setting in docker-compose.yml
hub:
image: selenium/hub
ports:
- "4444"
firefox:
image: selenium/node-firefox-debug
links:
- hub
ports:
- "5900"
chrome:
image: selenium/node-chrome-debug
volumes:
- /dev/shm:/dev/shm
links:
- hub
ports:
- "5900"
Hi all..
Actually I experience the same. I'm new in docker, and I found this issue is occur on my Windows Machine.
I've tried the -v /c/Users/<users>/some/path:/dev/shm and it's still not working, even I see some files added to the path.
Please help with this error..
Thanks
Thanks for he workaround, @elgalu solution worked for me, big time and straight away
Welcome @sloppylopez , my comment was a bit outdated so I updated with this:
Easiest option is sharing shm via docker run ... -v /dev/shm:/dev/shm
Other option is to use the new docker run option --shm-size=1g
Most helpful comment
Welcome @sloppylopez , my comment was a bit outdated so I updated with this:
Easiest option is sharing
shmviadocker run ... -v /dev/shm:/dev/shmOther option is to use the new docker run option
--shm-size=1g