Chrome Version: (copy from chrome://version)
OS: (e.g. Win10, MacOS 10.12, etc...)

What steps will reproduce the problem?
(1) Get chromedriver from https://chromedriver.storage.googleapis.com/2.41/chromedriver_linux64.zip

(2) ./chromedriver

(get port, for this repro, it was 9515)

(3) curl -X POST http://127.0.0.1:9515/session -d '{"desiredCapabilities":{"browserName":"chrome","platform":"LINUX"}}'

(get sessionId, for this repro, it was c4d2883b5f427c7d561e177f63eef6bb)

(4) curl -X POST http://127.0.0.1:9515/session/c4d2883b5f427c7d561e177f63eef6bb/execute -d '{"script":"return new Array(10000001).join(\"0\");","args":[]}'

(that works)

(5) curl -X POST http://127.0.0.1:9515/session/c4d2883b5f427c7d561e177f63eef6bb/execute -d '{"script":"return new Array(100000001).join(\"0\");","args":[]}'

What is the expected result?
What happens instead?
(that should work but causes chromedriver to segfault)

Note that this works with Firefox/Marionette/geckodriver. Note that for a large enough Array, I would expect a WebDriver error to occur. (Going 10X from this causes Firefox to return a WebDriver error saying the JavaScript engine OOM'd).

Note that:
new Array(100000001).join("0");
works in DevTools console.

Note that while Firefox console handles the 1000000001 case nicely, (eventually "InternalError: allocation size overflow", Chrome results in page crash & DevTools issues.

Why is it important Chrome/ChromeDriver handle large responses like other browsers/browser drivers?
Users' code coverage development workflows rely upon receiving potentially large responses over WebDriver, and they are starting to have to disable code coverage as their app codebase grows - or leave the Chrome/ChromeDriver ecosystem.