4

After about an hour of running my selenium browser will display an "Aw, Snap!" page, and I am unable to interact with the browser in any way from the console, and I have to close browser and re-start my script.

Is there an explanation or easy fix for this?

Aw Snap page display

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
zSomnolence
  • 41
  • 1
  • 2
  • 1
    Including your code that gets run to produce this error would be a good start to finding an answer. – CEH Dec 02 '19 at 21:42
  • I'm using the Selenium Chrome browser to crawl for location information. About ~1000 locations in the "Aw, Snap!" error occurs. I included a delete_all_cookies() after every ~250, thinking the browser might be overloaded, but that did not work. – zSomnolence Dec 02 '19 at 21:51
  • ^ This is a problem description, but still not a code sample. It might be better to just break up your URLs in a way that closes & re-initializes a WebDriver instance every 200 or so URLs. – CEH Dec 02 '19 at 22:12
  • Can't believe I didn't think of that! Thank you, I'll give that a try – zSomnolence Dec 02 '19 at 22:14
  • 1
    that page means you've lost your connection to the internet, so there's not much to be done about it except play the dinosaur game. – pcalkins Dec 02 '19 at 23:32
  • 1
    Aw snap doesn't mean no internet, it more likely means you're out of RAM – pguardiario Dec 03 '19 at 01:03

2 Answers2

5

This error screen...

Aw, Snap!

...implies that the ChromeDriver is having problems loading a new Browsing Context i.e. the Chrome Browser session.

Reason

You are seeing this error about an hour of running Chrome Browser based Selenium tests and this issue can occur due to reduced size of /dev/shm i.e. /dev/shm running out of space. As an example:

mount -o remount,size=64M /dev/shm

Ideally it should have been:

mount --bind /tmp/ /dev/shm/

While running Chromium in Docker environment 64M size is pretty much reduced state.

Deep dive

As per the discussion in Issue 522853: Linux: Chrome/Chromium SIGBUS/Aw, Snap! on small /dev/shm:

  • util_posix.cc:GetShmemTempDir on Linux attempts to always use /dev/shm for non-executable memory.
  • The required size of /dev/shm by large depends on the number of renderers, screen resolution, etc.
  • At time you may run out of memory due to large webapps even before running out of space in /dev/shm
  • At times some Docker containers decides to severely limit the size of their shared memory by default, which may be ok for some workloads, and probably prevents any container from hogging all the memory.

This issue was analyzed and discussed at length in the following discussions:

Solution

This issue was finally addressed through the commit / revision by fixing CreateAnonymousSharedMemory() not to leak FILE when returning fd.

CreateAnonymousSharedMemory() was modified to return the writable memory handle as a file-descriptor rather than as a FILE. Since POSIX does not provide a standard way to teardown a FILE without also close()ing the underlying file-descriptor, this was achieved by leaking the FILE. We now provide CreateAndOpenFdForTemporaryFileInDir(), to avoid the need to wrap the temporary-file descriptor into a FILE at all.

Conclusion

Ensure that:

  • /dev/shm/ is mounted with enough memory.
  • Selenium is upgraded to current levels Version 3.141.59.
  • ChromeDriver is updated to current ChromeDriver v79.0.3945.36 level.
  • Chrome is updated to current Chrome Version 79.0 level. (as per ChromeDriver v78.0 release notes)
  • Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
  • If your base Web Client version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Web Client.
  • Take a System Reboot.
  • Execute your @Test as non-root user.
undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
-1

I have the same problem, I worked around it by restarting my driver every 30 min automatically in withing the function.

Driss Bounouar
  • 3,182
  • 2
  • 32
  • 49