New issue
Advanced search Search tips

Issue 748419 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 705916



Sign in to add a comment

--headless --disable-gpu --repl results in loop printing of >>> {"result":{"type":"undefined"}}

Reported by emil.fih...@gmail.com, Jul 25 2017

Issue description

Chrome Version       : Google Chrome 59.0.3071.115
URLs (if applicable) : any
Other browsers tested: not applicable

What steps will reproduce the problem?
(1) Start Chrome with --headless --disable-gpu --repl and optionally an url

What is the expected result?
A shell

What happens instead?
>>> {"result":{"type":"undefined"}} is printed over and over again

Please provide any additional information below. Attach a screenshot if
possible.

Video of behaviour: https://emil.fi/jako/videot/2017-07-25_11-07-44_W857n0XS.mp4

 

Comment 1 Deleted

Tried on a friend's computer with Ubuntu, exact same behaviour.
Components: -Blink Internals>Headless
Status: Available (was: Unconfirmed)
This is caused by the google-chrome startup wrapper.

google-chrome in Ubuntu links to /opt/google/chrome/google-chrome which is a bash script that starts /opt/google/chrome/chrome

Lines 44-46 reference this security bug  http://crbug.com/376567  . The fix was to pipe /dev/null to stdin. When the repl starts, it receives a constant stream of \x0 bytes from /dev/null which cause the behavior above. Commenting out these lines fixes the issue.

A workaround is to execute the chrome binary directly and not use the startup script.

/opt/google/chrome/chrome --headless --disable-gpu --repl https://google.com/
@rysnxedg...

Ah, much thanks for explaining this. I also now understand why there are the cat processes as child when running Chrome (though it (that security bug solution) is extremely hacky, lazy and bad and should be fixed right away). From a user's standpoint those cat processes seem like (security) issues that don't exactly raise confidence in the software.

Anycase, a possible solution to this current issue here is to just warn the user about borked input when the startup script sees "--repl" in the argument list by informing about the pipes and/or recommending to use the binary directly.

Project Member

Comment 6 by sheriffbot@chromium.org, Jul 30

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 7 by bugdroid1@chromium.org, Sep 18

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/67fecf88ed445726d770d6e7e6b0cf746a995efb

commit 67fecf88ed445726d770d6e7e6b0cf746a995efb
Author: Fredrik Söderquist <fs@opera.com>
Date: Tue Sep 18 08:52:10 2018

Improve EOF handling in the headless REPL

When the REPL encounters an EOF, it can start spinning on just
generating a lot of empty ("") expressions.
Instead quit if an EOF is received and there's an empty expression. If
the expression is not empty it will still be evaluated. This helps
certain non-interactive use-cases.

Bug: 748419
Change-Id: Ica91f2164361bd6891f71e25fbdba0773c6c9941
Reviewed-on: https://chromium-review.googlesource.com/1225764
Reviewed-by: Eric Seckler <eseckler@chromium.org>
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#591979}
[modify] https://crrev.com/67fecf88ed445726d770d6e7e6b0cf746a995efb/headless/app/headless_shell.cc

Sign in to add a comment