New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 777410 link

Starred by 6 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
EstimatedDays: ----
NextAction: 2019-07-09
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Bad address access when using devtools protocol

Reported by logio...@gmail.com, Oct 23 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
This error occurs in google-chrome and chromium.

1. Client side

Client sends such commands using the dev tool protocol:

request: {"id":1,"method":"Page.navigate","params":{"url":"http:\/\/www.otsema.ru"}}
response: {"id":1,"result":{"frameId":"22429.1"}}
request: {"id":2,"method":"Runtime.evaluate","params":{"expression":"document.readyState"}}
response: {"id":2,"result":{"result":{"type":"string","value":"loading"}}}
request: {"id":3,"method":"Runtime.evaluate","params":{"expression":"document.readyState"}}
response: {"id":3,"result":{"result":{"type":"string","value":"loading"}}}
request: {"id":4,"method":"Runtime.evaluate","params":{"expression":"document.readyState"}}
...

2. Server side

chrome@0bafdccdb952:~$ /usr/bin/google-chrome-beta --version
Google Chrome 62.0.3202.62 beta
chrome@0bafdccdb952:~$ /usr/bin/google-chrome-beta --headless --disable-gpu --remote-debugging-port=40000 --remote-debugging-address=0.0.0.0 --no-sandbox

DevTools listening on ws://0.0.0.0:40000/devtools/browser/46d3e359-8ce2-42ad-9e4d-728a1fd03f4e
Bus error (core dumped)
chrome@0bafdccdb952:~$

I download chromium and repeate test:

chrome@0bafdccdb952:~$ ./chrome-linux/chrome --version
Chromium 64.0.3248.0
chrome@0bafdccdb952:~$ ./chrome-linux/chrome --headless --disable-gpu --remote-debugging-port=40000 --remote-debugging-address=0.0.0.0 --no-sandbox
DevTools listening on ws://0.0.0.0:40000/devtools/browser/466c0383-6a2c-4fb6-9138-85c7710b27a7
Received signal 7 BUS_ADRERR 7f47e4a61000
#0 0x7f4807105527 base::debug::StackTrace::StackTrace()
#1 0x7f480710508f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f4802dd18d0 <unknown>
#3 0x7f480751f420 Cr_z_inflate_fast
#4 0x7f480751e647 Cr_z_inflate
#5 0x7f4807874afc net::GzipSourceStream::FilterData()
#6 0x7f4807874660 net::FilterSourceStream::DoFilterData()
#7 0x7f48078742d8 net::FilterSourceStream::DoLoop()
#8 0x7f4807874171 net::FilterSourceStream::Read()
#9 0x7f480799db3f net::URLRequestJob::Read()
#10 0x7f4807997738 net::URLRequest::Read()
#11 0x7f4806110f7a content::ResourceLoader::ReadMore()
#12 0x7f4806111252 content::ResourceLoader::PrepareToReadMore()
#13 0x7f48061103dd content::ResourceLoader::CompleteResponseStarted()
#14 0x7f480610ff7a content::ResourceLoader::OnResponseStarted()
#15 0x7f480799e4f5 net::URLRequestJob::NotifyHeadersComplete()
#16 0x7f48079a1f82 net::URLRequestHttpJob::SaveCookiesAndNotifyHeadersComplete()
#17 0x7f48079a186f net::URLRequestHttpJob::OnStartCompleted()
#18 0x7f4807884bb5 net::HttpCache::Transaction::DoLoop()
#19 0x7f4807894834 net::HttpNetworkTransaction::OnIOComplete()
#20 0x7f48078b2bde net::HttpStreamParser::OnIOComplete()
#21 0x7f480794b1ae net::TCPClientSocket::DidCompleteRead()
#22 0x7f480794c8f1 net::TCPSocketPosix::ReadCompleted()
#23 0x7f480794e8cf net::SocketPosix::RetryRead()
#24 0x7f480794ecc7 net::SocketPosix::OnFileCanReadWithoutBlocking()
#25 0x7f480712299e base::MessagePumpLibevent::OnLibeventNotification()
#26 0x7f480719caae event_base_loop
#27 0x7f4807122c95 base::MessagePumpLibevent::Run()
#28 0x7f4807140435 base::RunLoop::Run()
#29 0x7f4805f60c76 content::BrowserThreadImpl::IOThreadRun()
#30 0x7f4805f60e71 content::BrowserThreadImpl::Run()
#31 0x7f480716ad7a base::Thread::ThreadMain()
#32 0x7f4807165fe3 base::(anonymous namespace)::ThreadFunc()
#33 0x7f4802dca0a4 start_thread
#34 0x7f47fcbdc04d clone
  r8: 00000d23edf4e000  r9: 00007f47e4a61000 r10: 00007f47e4a68eff r11: 00000d23ede8e050
 r12: 00000d23edf4e558 r13: 00000d23edf4edb8 r14: 000000000000765e r15: 00000d23ede8eb4b
  di: 00000d23edeeb230  si: 0000000000000076  bp: 0000000100000000  bx: 00000000000001ff
  dx: 0000000000000007  ax: 0000000000000010  cx: 0000000000000000  sp: 00007f47edcc7c68
  ip: 00007f480751f420 efl: 0000000000010246 cgf: 0000000000000033 erf: 0000000000000006
 trp: 000000000000000e msk: 0000000000000000 cr2: 00007f47e4a61000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
chrome@0bafdccdb952:~$

I copy last strace output which can be found here https://pastebin.com/raw/Lg7JhK72 if it may help.

I run chrome/chromium in docker container.

Dockerfile look likes as this text:

FROM debian

LABEL name="..." \
      mantainers="..." \
      description="headless chrome"

RUN useradd --create-home --user-group --system --groups audio,video --shell /bin/bash chrome

WORKDIR /home/chrome

RUN apt-get update && \
    apt-get install -y gnupg apt-transport-https vim procps ca-certificates wget supervisor

RUN touch /home/chrome/supervisor.sock && \
    chmod 777 /home/chrome/supervisor.sock && \
    ln -s /etc/supervisor/supervisord.conf /etc/supervisord.conf

RUN wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - && \
    echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list && \
    apt-get update && \
    apt-get install -y --allow-unauthenticated google-chrome-stable google-chrome-unstable google-chrome-beta

ADD supervisor/supervisord.conf /etc/supervisord.conf
ADD supervisor/chrome.conf /etc/supervisor/conf.d/chrome.conf

USER chrome

EXPOSE ...

CMD ["service", "supervisor", "stop"]
CMD ["/usr/bin/supervisord", "-c", "/etc/supervisord.conf"]

What is the expected behavior?
No errors

What went wrong?
Chromium die from SIGBUS signal

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 62.0.3202.62 beta  Channel: n/a
OS Version: Debian 3.16.0-4-amd64
Flash Version: 

I can't attach core file beacause it have size 270mb
 
Components: Platform>DevTools
Labels: Needs-Triage-M62

Comment 2 by logio...@gmail.com, Oct 24 2017

I spent a lot of time trying to reproduce the problem. As a result, i build docker image.

Load image
https://www.dropbox.com/s/s0790an1w21ihem/chrome-failed-image.tar?dl=0
docker load -i <image_tar_file>

To run container from image
docker run -tid -p 9222:9222 --name="chrome-failed" --privileged --security-opt seccomp=unconfined chrome-failed

To enter docker container
docker exec --user=root -ti <container id> bash

Chrome client
https://www.dropbox.com/s/lc5s95i8fv3zm2d/chrome_client.pl?dl=0
Script simply do Page.navigate and after a few seconds connection closed with code 1006

$ perl chrome_client.pl 
ws://127.0.0.1:9222/devtools/page/(AE3F34DFF8E8695B9E2E18E1A2295F79) at chrome_client.pl line 20.
{"id":0,"result":{"frameId":"(AE3F34DFF8E8695B9E2E18E1A2295F79)"}}
Use of uninitialized value $reason in concatenation (.) or string at chrome_client.pl line 36.
1006:  at chrome_client.pl line 36.
$

Components: Internals>Headless
Labels: TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to scripting and coding. Hence, adding TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!
Components: Internals>Network>Filters
Status: Untriaged (was: Unconfirmed)
Thanks for the detailed reproduction steps! Based on the stack trace this looks like a bug in the network layer.
Components: -Platform>DevTools
Cc: dvallet@chromium.org alexclarke@chromium.org
 Issue 781133  has been merged into this issue.
Cc: pfeldman@chromium.org
Components: -Internals>Network>Filters -Internals>Headless Platform>DevTools
Seems like this should be filed under the DevTools component.

+ Pavel for triage

Comment 8 by l...@chromium.org, Nov 13 2017

Owner: allada@chromium.org
Status: Assigned (was: Untriaged)
allada@, I'm not familiar with network enough to see the relationship between this and the dupe  https://crbug.com/781133 

Could you please help confirm, and take a look if this is DevTools related?

Comment 9 by logio...@gmail.com, Dec 6 2017

I don't understand what is going on in this issue, but i want to add new stack traces of failed chromium.

# ./chrome --version
Chromium 65.0.3287.0

1. I attempt to test new version chrome and i've got this stack traces
http://paste.ubuntu.com/26125312/
http://paste.ubuntu.com/26125325/
http://paste.ubuntu.com/26125383/
http://paste.ubuntu.com/26125543/

2. Also I'm trying to run three instances of chromium on one machine and send to it requests.

./chrome --headless --disable-gpu --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-port=40000 --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0" --user-data-dir=/home/chrome/chrome_40000
./chrome --headless --disable-gpu --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-port=40001 --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0" --user-data-dir=/home/chrome/chrome_40001
./chrome --headless --disable-gpu --no-sandbox --remote-debugging-address=0.0.0.0 --remote-debugging-port=40002 --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0" --user-data-dir=/home/chrome/chrome_40002

And i've got this stack traces

http://paste.ubuntu.com/26125639/
http://paste.ubuntu.com/26125651/
http://paste.ubuntu.com/26125670/

What is the status on this issue?

Components: -Platform>DevTools Internals>Network
Thanks for the call stacks. Now I've had a second look, they don't jump out as being DevTools related to me.  Perhaps we should see if the net folks can triage these better.


Owner: ----
Status: Untriaged (was: Assigned)
As per comment #10, does not look network-related. Over to net/ for triage.
Components: -Internals>Network
Labels: Needs-Feedback
These stack traces seem to be in various different places.  Some in the net/ stack, some in <unknown> code, some in content::ResourceLoader, several in Skia.  The only commonality I can see if they generally seem to be in decompression code, but that may just be an artifact of where the CPU spends a lot of time.

Can you reproduce these crashes without using devtools? without any command line options? on other machines?

I'm removing the network tag until we can narrow down what's going on a bit.

Comment 13 by logio...@gmail.com, Jan 12 2018

I can't reproduce crashes without devtools.
I have reproduced the problem, at least on three different machines.

You may reproduce problem too.
I have prepared for you archive with Dockerfile and Readme on how to reproduce problem.

chrome_docker.tar.gz
66.6 KB Download

Comment 14 by logio...@gmail.com, Jan 24 2018

is there any progress in this issue?
Labels: Pri-3
NextAction: 2019-07-09
Downgrading P2s that haven't been modified in more than 6 months, which have no component or owner.

Sign in to add a comment