ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context : while initializing Chrome bro

I am getting this error when I attempt to run code on 2 of 3 computers:

[0502/155335.565:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context.

Here is the code:

from selenium import webdriver from selenium.webdriver.chrome.options import Options import os chrome_options = Options() chrome_options.add_argument("--headless") chrome_options.add_argument("--disable-gpu") chrome_options.add_argument("--window-size=1920x1080") chrome_driver = os.getcwd() + "\\chromedriver.exe" print "chrome driver:" + chrome_driver driver = webdriver.Chrome(chrome_options=chrome_options, executable_path=chrome_driver) driver.get("http://www.google.com") luck_button = driver.find_element_by_css_selector("[name=btnI") luck_button.click() driver.get_screenshot_as_file("capture.png")

Now I have checked all of the systems, they are running windows 10 64-bit, google chrome 64 bit Version: 66.0.3359.139, python 2.7 32-bit, chromedriver.exe 32-bit, pycharm 2018.1.1

funny thing is if I run this without the headless options then everything works. The browser pops up, the "I'm feeling lucky" button is pressed, and a screen shot is taken. Only if I add in the headless bit does this error occur.

I am not sure what could be different on 1 system that would allow this to work when the other systems are running the same software.

Answer1:

When <strong>Headless Chrome</strong> was first released as <strong>GA (General Availability)</strong> by Google Team the article <strong>Getting Started with Headless Chrome</strong> mentioned that :

--disable-gpu \ # Temporarily needed if running on Windows.

A note was added as :

Right now, you'll also want to include the --disable-gpu flag if you're running on Windows.

As per the discussion <strong>Headless: make --disable-gpu flag unnecessary</strong> it was clear that :

The --disable-gpu flag is no longer necessary on Linux or Mac OSX. It will also become unnecessary on Windows as soon as the bug <strong>SwiftShader fails an assert on Windows in headless mode</strong> is fixed.

What happened under the hood?

As per the discussion <strong>headless: Switch from osmesa to SwiftShader</strong> as Google/Chromium team decided to ship <strong>SwiftShader</strong> with <strong>Chrome</strong> the team thought to start using it to render GL content in Headless Mode. This required a couple of changes as follows :

    <li>Skip GPU data collection in Headless Mode since <strong>SwiftShader</strong> isn't considered a software implementation by that code which lead to a failure when we tried to retrieve information from the <strong>Window System</strong>.</li> <li>Only skip GL initialization in InitializeStaticEGLInternal if we intend to use <strong>osmesa</strong>. <strong>SwiftShader</strong> requires initialization like the other non-software implementations.</li> <li><strong>SwiftShader</strong> is currently not supported on Mac OSX, so the team decided to continue to use the physical GPU in Headless Mode on that platform (unlike on other platforms where everything is software rendered).</li> <li>So, to disable <strong>WebGL</strong> support in Headless Mode they decided to use <strong>--disable-gpu</strong> and <strong>--disable-software-rasterizer</strong></li> </ul>

    The idea to <strong>Support WebGL in headless</strong> is still under discussion but <strong>SwiftShader fails an assert on Windows in headless mode</strong> with an error as :

    [0117/125830.649194:ERROR:gpu_process_transport_factory.cc(1043)] Lost UI shared context. DevTools listening on ws://127.0.0.1:37429/devtools/browser/1f0b2bf7-dfdd-44ac-9da7-f2659d352f0d

    Conclusion

    This error doesn't impact your @Test and you can ignore the error for the time being.

    人吐槽 人点赞

Recommend

Comment

用户名: 密码:
验证码: 匿名发表

你可以使用这些语言

查看评论:ERROR:gpu_process_transport_factory.cc(1007)] Lost UI shared context : while initializing Chrome bro