I have a feeling what I've just filed here is a dupe, however I was unable to find anything in my searches related to WebGL specifically being presented as disabled to web content asking for it (unless the summary to said issue has been changed to something more component specific on what's broken). My apologies if it is indeed a dupe.

Please provide the contents of about:gpu from each Chrome installation.

Attached saves from the chrome://gpu page for both dev/unstable and stable. For unstable, the page runs on forever and the tab pegs the CPU at 100% until it gets closed. Stable had no issues loading up the page. Ran one after the other.

Deleted: gpu - 62.0.3202.94 (Official Build) (64-bit).html 4.6 KB

gpu - 62.0.3202.94 (Official Build) (64-bit).html 4.6 KB View Download

Deleted: gpu - 64.0.3278.0 (Official Build) dev (64-bit).html 4.8 KB

gpu - 64.0.3278.0 (Official Build) dev (64-bit).html 4.8 KB View Download

Thank you for providing more feedback. Adding requester "kbr@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

Both html do not contain valid info. Maybe copy and paste into a txt file?

Here are the outputs in copy/paste txt files.

Deleted: gpu - 62.0.3202.94 (Official Build) (64-bit).txt 11.4 KB

gpu - 62.0.3202.94 (Official Build) (64-bit).txt 11.4 KB View Download

Deleted: gpu - 64.0.3278.0 (Official Build) dev (64-bit).txt 5.7 KB

gpu - 64.0.3278.0 (Official Build) dev (64-bit).txt 5.7 KB View Download

Thank you for providing more feedback. Adding requester "zmo@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

It's because GPU process crashed multiple times, so Chrome switched to SwiftShader.

Why do you need to run with --ignore-gpu-blacklist in the first place?

Can you run M64 with no extra commandline switch, but only --user-data-dir=/tmp/hdygfd (any clean dir)? Let us know what happens and also provide about:gpu for that.

I am not voluntarily invoking --ignore-gpu-blacklist. Looking through all my KDE shortcuts and bash aliases the only instance of google-chrome-unstable I find seems pretty normal...

/usr/bin/google-chrome-unstable %U

And my bash tells me...

$ which google-chrome-unstable
/usr/bin/google-chrome-unstable

I've attached a screenshot of what htop sees concerning the initial google-chrome-unstable instance and all the child processes.

The second screenshot and text file is from a clean profile instance of Chrome 64 running from a terminal. I see the same results of broken WebGL support.

Deleted: 20171130172346-~-home-rubin110 : htop — Konsole.png 1.3 MB

	20171130172346-~-home-rubin110 : htop — Konsole.png 1.3 MB View Download

Deleted: 20171130172727-Selection.png 578 KB

	20171130172727-Selection.png 578 KB View Download

Deleted: cleanprofile - gpu - 64.0.3278.0 (Official Build) dev (64-bit).txt 3.9 KB

cleanprofile - gpu - 64.0.3278.0 (Official Build) dev (64-bit).txt 3.9 KB View Download

The clean profile definitely has fewer command line arguments than your default one.

Something's causing Chrome's GPU sub-process to crash. We test on Intel GPUs in house but not on Debian Sid specifically (we test on Ubuntu Xenial/Zesty). CC'ing some Intel folks who may be able to help.

Are there any crash IDs on the about:crahes page? If so can you post them here?

Thanks for cc, @kbr. 

I simply tried to access the website on my Ubuntu Desktop with chromium I built 10 days ago. It is OK. WebGL 2 runs well. I will try to build the latest Chromium and download the dev version to have a try. 

BTW, the attached file at #8 shows that it is caused by the context creation failure. And it fails to create context for Canvas/Flash/Compositing/Rasterization, and WebGL 2 as well. But WebGL is OK in the attached file. 

There are two crashes for today, neither time stamp reminds me of anything particularly horrible happening to my experience using Chrome...

Uploaded Crash Report ID 8559bb9b97ac31c7 (Local Crash ID: Chrome)
Crash report uploaded on Thursday, November 30, 2017 at 3:58:29 PM

Uploaded Crash Report ID 67429c236921fda4 (Local Crash ID: Chrome)
Crash report uploaded on Thursday, November 30, 2017 at 3:58:28 PM

The crash prior to those are on the 15th, which is well before me seeing this issue starting with updating the google-chrome-unstable package through apt-get install from yesterday.

I'm pretty sure I don't understand how this works, but from my perspective whatever process I kick off starting Chrome through running google-chrome-unstable has a whole lot of children. At some point one of these children pops up with a ton of arguments I never specified. I don't know where those arguments come from.

Here's a screenshot from htop with the initial process of google-chrome-unstable --user-data-dir=/tmp/ergoifdjg that I started through a terminal, PID 18298. Once I've got a browser window, there are a ton of other child processes. In that screenshot you can see a child, PID 19038, show up with a dozen arguments...

$ ps aux | grep 19038
rubin110 19038  0.6  0.5 1091568 88160 pts/5   Sl+  21:35   0:00 /opt/google/chrome-unstable/chrome --type=renderer --field-trial-handle=6970114020081771632,8927432432717694701,131072 --disable-gpu-compositing --service-pipe-token=4E01BBC5FD560A16FD97F69282A60149 --lang=en-US --user-data-dir=/tmp/ergoifdjg --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --enable-pinch --num-raster-threads=2 --enable-main-frame-before-activation --enable-gpu-async-worker-context --content-image-texture-target=0,0,3553;0,1,3553;0,2,3553;0,3,3553;0,4,3553;0,5,3553;0,6,3553;0,7,3553;0,8,3553;0,9,3553;0,10,3553;0,11,3553;0,12,3553;0,13,3553;0,14,3553;0,15,3553;0,16,3553;0,17,3553;0,18,3553;1,0,3553;1,1,3553;1,2,3553;1,3,3553;1,4,3553;1,5,3553;1,6,3553;1,7,3553;1,8,3553;1,9,3553;1,10,3553;1,11,3553;1,12,3553;1,13,3553;1,14,3553;1,15,3553;1,16,3553;1,17,3553;1,18,3553;2,0,3553;2,1,3553;2,2,3553;2,3,3553;2,4,3553;2,5,3553;2,6,3553;2,7,3553;2,8,3553;2,9,3553;2,10,3553;2,11,3553;2,12,3553;2,13,3553;2,14,3553;2,15,3553;2,16,3553;2,17,3553;2,18,3553;3,0,3553;3,1,3553;3,2,3553;3,3,3553;3,4,3553;3,5,3553;3,6,3553;3,7,3553;3,8,3553;3,9,3553;3,10,3553;3,11,3553;3,12,3553;3,13,3553;3,14,3553;3,15,3553;3,16,3553;3,17,3553;3,18,3553;4,0,3553;4,1,3553;4,2,3553;4,3,3553;4,4,3553;4,5,3553;4,6,3553;4,7,3553;4,8,3553;4,9,3553;4,10,3553;4,11,3553;4,12,3553;4,13,3553;4,14,3553;4,15,3553;4,16,3553;4,17,3553;4,18,3553;5,0,3553;5,1,3553;5,2,3553;5,3,3553;5,4,3553;5,5,3553;5,6,3553;5,7,3553;5,8,3553;5,9,3553;5,10,3553;5,11,3553;5,12,3553;5,13,3553;5,14,3553;5,15,3553;5,16,3553;5,17,3553;5,18,3553;6,0,3553;6,1,3553;6,2,3553;6,3,3553;6,4,3553;6,5,3553;6,6,3553;6,7,3553;6,8,3553;6,9,3553;6,10,3553;6,11,3553;6,12,3553;6,13,3553;6,14,3553;6,15,3553;6,16,3553;6,17,3553;6,18,3553 --disable-accelerated-video-decode --service-request-channel-token=4E01BBC5FD560A16FD97F69282A60149 --renderer-client-id=34 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101,v8_snapshot_data:102
rubin110 19632  0.0  0.0  12808   964 pts/7    S+   21:36   0:00 grep --color=always 19038

So yeah, both a clean profile and my current profile eventually spawn a child that has all those arguments. My assumption has been that it's something Chrome figures out and does on its own. Is that not the case?

Deleted: 20171130213649-~-home-rubin110 : htop — Konsole.png 915 KB

	20171130213649-~-home-rubin110 : htop — Konsole.png 915 KB View Download

Thank you for providing more feedback. Adding requester "kbr@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

I just copied my Chrome 64 profile over to 62...

$ rm -R google-chrome
$ cp -R google-chrome-unstable google-chrome
$ google-chrome

No issues with the WebGL test page I linked in the original report, nor with chrome://gpu.

Thanks for your feedback. The flags:

--num-raster-threads=2 --enable-main-frame-before-activation --enable-gpu-async-worker-context --content-image-texture-target=...

indicate to me there's some sort of experiment being run. That would explain why the behavior only starts a little while after starting the browser with a new user profile, because it takes that amount of time for the experiment framework to start up.

ericrk, brianderson, sunnyps: are you familiar with these command line flags and any experiments that might be controlling them? I'm guessing that when one of them activates, it causes the GPU process to start crashing. That might be unfounded though and maybe the GPU process is always crashing on this user's machine.

Submitter, by the way, the crashes you reported were all in the clipboard code in the Blink rendering engine and aren't related to WebGL being disabled.

Thread 0 (id: 31380) CRASHED [SIGILL @ 0x0000560119c7e6f6 ] MAGIC SIGNATURE THREAD
Stack Quality87%Show frame trust levels
0x0000560119c7e6f6	(chrome -node_channel.cc:895 )	mojo::edk::NodeChannel::SendChannelMessage(std::__1::unique_ptr<mojo::edk::Channel::Message, std::__1::default_delete<mojo::edk::Channel::Message> >)
0x0000560119c79b59	(chrome -node_controller.cc:651 )	mojo::edk::NodeController::ForwardEvent(mojo::edk::ports::NodeName const&, std::__1::unique_ptr<mojo::edk::ports::Event, std::__1::default_delete<mojo::edk::ports::Event> >)
0x000056011746ff61	(chrome -node.cc:834 )	mojo::edk::ports::Node::SendUserMessage(mojo::edk::ports::PortRef const&, std::__1::unique_ptr<mojo::edk::ports::UserMessageEvent, std::__1::default_delete<mojo::edk::ports::UserMessageEvent> >)
0x0000560119c78300	(chrome -node_controller.cc:295 )	mojo::edk::NodeController::SendUserMessage(mojo::edk::ports::PortRef const&, std::__1::unique_ptr<mojo::edk::ports::UserMessageEvent, std::__1::default_delete<mojo::edk::ports::UserMessageEvent> >)
0x0000560119c757fd	(chrome -message_pipe_dispatcher.cc:145 )	mojo::edk::MessagePipeDispatcher::WriteMessage(std::__1::unique_ptr<mojo::edk::ports::UserMessageEvent, std::__1::default_delete<mojo::edk::ports::UserMessageEvent> >, unsigned int)
0x0000560119c6e042	(chrome -core.cc:708 )	mojo::edk::Core::WriteMessage(unsigned int, unsigned long, unsigned int)
0x0000560118a55214	(chrome -message_pipe.h:94 )	mojo::Connector::Accept(mojo::Message*)
0x00005601173010f6	(chrome -clipboard.mojom.cc:822 )	content::mojom::ClipboardHostProxy::WriteHtml(ui::ClipboardType, std::__1::basic_string<unsigned short, base::string16_internals::string16_char_traits, std::__1::allocator<unsigned short> > const&, GURL const&)
0x000056011c2a983e	(chrome -webclipboard_impl.cc:167 )	content::WebClipboardImpl::WriteHTML(blink::WebString const&, blink::WebURL const&, blink::WebString const&, bool)
0x000056011b1ec658	(chrome -Pasteboard.cpp:132 )	blink::Pasteboard::WriteHTML(WTF::String const&, blink::KURL const&, WTF::String const&, bool)
0x000056011b39e2ba	(chrome -Editor.cpp:562 )	blink::Editor::WriteSelectionToPasteboard()
0x000056011b39fd4e	(chrome -Editor.cpp:1201 )	blink::Editor::Copy(blink::EditorCommandSource)
0x000056011b3e9af5	(chrome -EditorCommand.cpp:674 )	blink::ExecuteCopy(blink::LocalFrame&, blink::Event*, blink::EditorCommandSource, WTF::String const&)
0x000056011b3e9268	(chrome -EditorCommand.cpp:2994 )	blink::Editor::ExecuteCommand(WTF::String const&, WTF::String const&)
0x000056011b4ed482	(chrome -WebLocalFrameImpl.cpp:1060 )	blink::WebLocalFrameImpl::ExecuteCommand(blink::WebString const&, blink::WebString const&)
0x000056011bd31140	(chrome -render_frame_impl.cc:4408 )	content::RenderFrameImpl::HandleCurrentKeyboardEvent()
0x000056011b6c1732	(chrome -EditorKeyBindings.cpp:85 )	blink::Editor::HandleKeyboardEvent(blink::KeyboardEvent*)
0x000056011b6c11ad	(chrome -KeyboardEventManager.cpp:292 )	blink::KeyboardEventManager::DefaultKeyboardEventHandler(blink::KeyboardEvent*, blink::Node*)
0x000056011b384ec7	(chrome -EventDispatcher.cpp:313 )	blink::EventDispatcher::Dispatch()
0x000056011b384313	(chrome -EventDispatcher.cpp:57 )	blink::EventDispatcher::DispatchEvent(blink::Node&, blink::Event*)
0x000056011b6c0e41	(chrome -KeyboardEventManager.cpp:236 )	blink::KeyboardEventManager::KeyEvent(blink::WebKeyboardEvent const&)

> --num-raster-threads=2 --enable-main-frame-before-activation --enable-gpu-async-worker-context --content-image-texture-target=...

These are probably things changed from non-default in about:flags, not part of some experiment afaik. Most/all of these affect how the renderer behaves, not the gpu process.

> ericrk, brianderson, sunnyps: are you familiar with these command line
> flags and any experiments that might be controlling them? I'm guessing that
> when one of them activates, it causes the GPU process to start crashing.
> That might be unfounded though and maybe the GPU process is always crashing
> on this user's machine.

OP, you could look for these in your about:flags to turn them off/back to defaults to confirm or reject this idea?

I think may need to reproduce or get a crash report of the gpu process to know what to do next. Can you confirm that crash reporting is enabled in your chrome settings?

Reporter: I think it's really hard to see what's going on here without full crash reports. Could you try (on a fresh profile, or with all of the about:flags reset to default):
* restart chrome (making sure it exited completely)
* check if there are "The GPU process crashed!" entries in about:gpu
* if not, see if using the browser or webgl causes the GPU process to crash
* see if there are any new entries in about:crashes, and send the crash IDs (may take a little time to upload)

These flags are always set automatically and don't indicate an experiment or anything non-default in about:flags.

From the source:

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_process_host_impl.cc?sq=package:chromium&l=2414

--num-raster-threads and --enable-main-frame-before-activation are set automatically based on number of cpu cores detected at runtime.

--enable-gpu-async-worker-context is appended by default, unless explicitly disabled.

 --content-image-texture-target is also appended by default.

If I run a fresh profile all of my flags are reset, however I still see this issue of WebGL content not working. There are no new entries in chrome://crashes. Is there any way I can invoke the generation of a crash report for you?

Thanks.

Thank you for providing more feedback. Adding requester "danakj@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

Is "Automatically send usage statistics and crash reports to Google" enabled in settings?

Always and forever. It's not a thing I generally turn off.

Deleted: 20171201160341-Selection.png 8.8 KB

	20171201160341-Selection.png 8.8 KB View Download

+mark any ideas how we can figure out how to get crash reports for this?

I can not reproduce the failure. Device = 1916 in about:gpu shows that the failure might be specific for Intel HD Graphics 520. I will try to find out such a device to reproduce the issue.  

My machine is a Thinkpad X1 Carbon 4th gen (not the Yoga). 

If it helps to get this bug fixed, I would be happy to bike out to the Google building in San Francisco and repro the bug on my machine for anyone. Even would be willing to Caltrain down to the Google Plex (or anywhere else in the South Bay) if that's where this team is located or anyone else who wants to see this bug. 

If nothing’s showing up in chrome://crashes and reporting is already turned on, then it’s beyond Breakpad’s abilities (it may not be beyond Crashpad’s, but we won’t be there on Linux until next quarter). The best thing I can suggest at this point is to attach a debugger, or to allow core files to be saved and to then run a debugger on one that’s generated.

Although we may not have crash reports right now, we might still have logged some errors from GPU process before crashing.

Can you follow the instructions at https://www.chromium.org/for-testers/enable-logging and run chrome in a clean user-data-dir and provide us the chromium_debug.log file?

Marking as needs-feedback

Surprise surprise. I am now unable to reproduce this issue with 64.0.3282.14 (Official Build) dev (64-bit). I can hit the webgl test I linked to in the description of the bug, and all my other webgl sites are loading fine now. chrome://gpu also seems to report that everything is working fine (as far as I can read) with my personal Chrome profile loaded (attached).

I don't know who fixed it, but thanks!

Deleted: gpu - 64.0.3282.14 (Official Build) dev (64-bit).txt 16.8 KB

gpu - 64.0.3282.14 (Official Build) dev (64-bit).txt 16.8 KB View Download

Thank you for providing more feedback. Adding requester "kainino@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

Thanks for letting us know.