Issue metadata
Sign in to add a comment
|
Headless crash with request interception to a file:// URL containing text
Reported by
jim.muss...@gmail.com,
Nov 3 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36
Steps to reproduce the problem:
Example puppeteer script attached.
$ node test.js
Using puppeteer version 0.12.0
$ ./node_modules/puppeteer/.local-chromium/linux-508693/chrome-linux/chrome --version
Chromium 64.0.3240.0
1. Simple local page that causes a network request to a http resource (I can repro with `<script src="...">`, `<img src="">` and `style="background-image:url(...)"` for example.
2. Enable request interception and use `request.continue({url: 'file:///path/to/file'})`
3. Chrome crashes if path/to/file is a text file.
Examples that crash:
https://example.com/example.js --> file:///path/example.js
https://example.com/example.png --> file:///path/example.svg
Examples that don't crash:
https://example.com/example.js --> file:///path/example.png (fails to parse of course, but no crash)
https://example.com/example.png --> file:///path/example.jpg
So it appears to be something specific to the file containing text. example.js is a one-line javascript file, no utf-8 bytes or anything outside ascii printable. example.png and example.svg are valid png and svg files.
What is the expected behavior?
Not crashing.
What went wrong?
I've attached a full log, but here's the stack trace.
Received signal 11 SEGV_MAPERR 000000000008
#0 0x561603e4b857 base::debug::StackTrace::StackTrace()
#1 0x561603e4b3bf base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f6507fbdda0 <unknown>
#3 0x561604522817 net::HttpResponseHeaders::EnumerateHeader()
#4 0x5616060d5cab content::SiteIsolationStatsGatherer::OnReceivedResponse()
#5 0x5616060c260a content::ResourceDispatcher::OnReceivedResponse()
#6 0x5616060d73ae content::URLLoaderClientImpl::OnReceiveResponse()
#7 0x561602965ebb content::ThrottlingURLLoader::OnReceiveResponse()
#8 0x5616027a1a3b content::mojom::URLLoaderClientStubDispatch::Accept()
#9 0x5616047fad31 mojo::internal::MultiplexRouter::ProcessIncomingMessage()
#10 0x5616047fa5b0 mojo::internal::MultiplexRouter::Accept()
#11 0x5616047f3055 mojo::Connector::ReadSingleMessage()
#12 0x5616047f3752 mojo::Connector::ReadAllAvailableMessages()
#13 0x561602c6bf80 net::(anonymous namespace)::CallInt64ToInt()
#14 0x561604803254 mojo::SimpleWatcher::OnHandleReady()
#15 0x561603e4c797 base::debug::TaskAnnotator::RunTask()
#16 0x561603aaef8c blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#17 0x561603aad0a9 blink::scheduler::TaskQueueManager::DoWork()
#18 0x561603e4c797 base::debug::TaskAnnotator::RunTask()
#19 0x561603e65fd4 base::MessageLoop::RunTask()
#20 0x561603e66497 base::MessageLoop::DoWork()
#21 0x561603e6852a base::MessagePumpDefault::Run()
#22 0x561603e86985 base::RunLoop::Run()
#23 0x56160745b804 content::RendererMain()
#24 0x561603b97214 content::RunZygote()
#25 0x561603b98421 content::ContentMainRunnerImpl::Run()
#26 0x561603ba119d service_manager::Main()
#27 0x561603b96f52 content::ContentMain()
#28 0x561607a91075 headless::(anonymous namespace)::RunContentMain()
#29 0x561607a90f1d headless::RunChildProcessIfNeeded()
#30 0x561603b9d816 headless::HeadlessShellMain()
#31 0x5616026001bd ChromeMain
#32 0x7f6501bb7f6a __libc_start_main
#33 0x561602600029 <unknown>
r8: 000000000000006e r9: 000000000000000a r10: 00000000ffff0001 r11: 0000000000000001
r12: 00007ffc7e4248a0 r13: 0000000000000000 r14: 00007ffc7e4248c0 r15: 0000000000000000
di: 0000000000000000 si: 0000000000000000 bp: 0000149b806952b0 bx: 00007ffc7e424968
dx: 00007ffc7e4248a0 ax: 00005616000e5bae cx: 00007ffc7e4248c0 sp: 00007ffc7e424860
ip: 0000561604522817 efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
[end of stack trace]
Did this work before? N/A
Chrome version: 64.0.3240.0 Channel: n/a
OS Version: Puppeteer 0.12.0 (linux-508693)
Flash Version:
,
Nov 5 2017
Thanks for the detail report and for providing the stack trace! My guess is that this also doesn't work on non-headless Chrome, is that right? cc'ing alexclarke@ who implemented request interception.
,
Nov 5 2017
I'm duping this into https://crbug.com/777410. It seems like it might be related
,
Nov 22 2017
I'm not sure that dupe is related?
Update: Good news! Looks like the crash is fixed in 0.13.0
$ ./node_modules/puppeteer/.local-chromium/linux-515411/chrome-linux/chrome --version
Chromium 64.0.3264.0
But now it seems to be confused about content type for any content coming from file:/// URLs.
In the attached repro, request interception is enabled but should no-op. It just loads a simple HTML file with no external resources. The result is that page.content() is:
<html><head></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;"><!doctype html>
<html>
<head>
</head>
<body>
hello
</body>
</html>
</pre></body></html>
(i.e. it treated page.html like a plain text file).
If you comment out:
await page.setRequestInterception(true);
captureRequests(page);
then the content is loaded correctly.
<!DOCTYPE html><html><head>
</head>
<body>
hello
</body></html>
Thanks
,
Dec 4 2017
,
Dec 4 2017
Issue 791439 has been merged into this issue.
,
Dec 4 2017
Thank you for providing more feedback. Adding requester "dvallet@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 11 2017
@caseq: could you please take a look on this crash?
,
Dec 11 2017
,
Dec 13 2017
I can confirm this bug. It happens when i use the devtool remote protocol - in this example the puppeteer package. I can open a tab manually and it works just fine, but with the API it fails.
,
Jan 22 2018
Just to provide some info on why this might be worth fixing: unfortunately because of this bugs users of the popular critical and penthouse modules for extracting critical pages CSS are stuck on older versions of chrome (i.e. one that does not run well in docker). This bug is a bit hard to track down all the way here so i assume there are a few more users that would like to see this fixed than that starred here. Just posting because i've noticed it's in the same priority category as some regressions in the 1-2% range. Thanks :)
,
Feb 19 2018
If anything is needed before this can be fixed, let me know. I can provide sample code or anything else that would be useful.
,
Feb 22 2018
I think we fixed this in recent versions as a side effect of some other change, at least I couldn't reproduce this on ToT. Andrey kindly offered help to bisect this.
,
Feb 22 2018
I bisected this down to the https://chromium.googlesource.com/chromium/src/+log/ae0b6dec0efab03128fe505d4d88e0ede1aa080a..978f3c4fb8e40a697b9d83736f127287114f9af2 This seems to be fixed with https://chromium-review.googlesource.com/c/chromium/src/+/751402
,
Feb 23 2018
I tried it out with the puppeteer package and with version `win64-536395` (I have no idea how the version numbers work), this seems to work again. Thanks!
,
Mar 7 2018
From what I can see this has regressed and is back to not working again. In essence it was broken, then: ✅Chromium 65.0.3312.0 (r526987), introduced in 1.0.0 (fixed this issue) ❌Chromium 66.0.3348.0 (r536395), introduced in 1.1.0 (broke it again) https://github.com/GoogleChrome/puppeteer/issues/1506#issuecomment-371227988
,
Apr 7 2018
Just pinging that this is still broken: ❌ Chromium 67.0.3372.0 (r543305) (tested via https://github.com/GoogleChrome/puppeteer/releases/tag/v1.2.0)
,
Apr 18 2018
@jonas: I believe this is fixed upstream now with https://chromium.googlesource.com/chromium/src/+/2a762c05ecee700c23d24352691540bd2eb10df3 |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by meade@chromium.org
, Nov 3 2017