Backtrace:
        base::debug::StackTrace::StackTrace [0x0000000000A62E45+69]
        base::debug::StackTrace::StackTrace [0x0000000000A62968+24]
        logging::LogMessage::~LogMessage [0x0000000000AD50C0+112]
        base::internal::Invoker<base::internal::BindState<base::Callback<void __cdecl(unsigned int,int),1,1>,unsigned int,int>,void __cdecl(void)>::Run [0x000000000CAAB019+297]
        cc::GLRenderer::DrawContentQuadNoAA [0x000000000CA9D526+534]
        cc::GLRenderer::DrawContentQuad [0x000000000CA9C4DF+495]
        cc::GLRenderer::DrawTileQuad [0x000000000CA9FB34+52]
        cc::GLRenderer::DoDrawQuad [0x000000000CA9C190+912]
        cc::DirectRenderer::DrawRenderPass [0x000000000CA6BB2A+1802]
        cc::DirectRenderer::DrawRenderPassAndExecuteCopyRequests [0x000000000CA6BE31+177]
        cc::DirectRenderer::DrawFrame [0x000000000CA6AFC7+3703]
        cc::Display::DrawAndSwap [0x0000000016600215+3125]
        cc::DisplayScheduler::DrawAndSwap [0x000000001660D2EF+559]
        cc::DisplayScheduler::AttemptDrawAndSwap [0x000000001660C205+133]
        cc::DisplayScheduler::OnBeginFrameDeadline [0x000000001660DAD2+354]
        ??$Invoke@AEBV?$WeakPtr@VDisplayScheduler@cc@@@base@@$$V@?$FunctorTraits@P8DisplayScheduler@cc@@EAAXXZX@internal@base@@SAXP8DisplayScheduler@cc@@EAAXXZAEBV?$WeakPtr@VDisplayScheduler@cc@@@2@@Z [0x0000000016607606+38]
        ??$MakeItSo@AEBQ8DisplayScheduler@cc@@EAAXXZAEBV?$WeakPtr@VDisplayScheduler@cc@@@base@@$$V@?$InvokeHelper@$00X@internal@base@@SAXAEBQ8DisplayScheduler@cc@@EAAXXZAEBV?$WeakPtr@VDisplayScheduler@cc@@@2@@Z [0x00000000166079FA+74]
        base::internal::Invoker<base::internal::BindState<void (__cdecl cc::DisplayScheduler::*)(void) __ptr64,base::WeakPtr<cc::DisplayScheduler> >,void __cdecl(void)>::RunImpl<void (__cdecl cc::DisplayScheduler::*const & __ptr64)(void) __ptr64,std::tuple<base:: [0x0000000016607B4C+76]
        base::internal::Invoker<base::internal::BindState<void (__cdecl cc::DisplayScheduler::*)(void) __ptr64,base::WeakPtr<cc::DisplayScheduler> >,void __cdecl(void)>::Run [0x000000001660E5A3+51]
        base::Callback<void __cdecl(void),1,1>::Run [0x000000001660E50A+42]
        base::CancelableCallback<void __cdecl(void)>::Forward [0x000000001660D56A+26]
        ??$Invoke@AEBV?$WeakPtr@V?$CancelableCallback@$$A6AXXZ@base@@@base@@$$V@?$FunctorTraits@P8?$CancelableCallback@$$A6AXXZ@base@@EBAXXZX@internal@base@@SAXP8?$CancelableCallback@$$A6AXXZ@2@EBAXXZAEBV?$WeakPtr@V?$CancelableCallback@$$A6AXXZ@base@@@2@@Z [0x00000000166075C6+38]
        ??$MakeItSo@AEBQ8?$CancelableCallback@$$A6AXXZ@base@@EBAXXZAEBV?$WeakPtr@V?$CancelableCallback@$$A6AXXZ@base@@@2@$$V@?$InvokeHelper@$00X@internal@base@@SAXAEBQ8?$CancelableCallback@$$A6AXXZ@2@EBAXXZAEBV?$WeakPtr@V?$CancelableCallback@$$A6AXXZ@base@@@2@@Z [0x000000001660798A+74]
        base::internal::Invoker<base::internal::BindState<void (__cdecl base::CancelableCallback<void __cdecl(void)>::*)(void)const __ptr64,base::WeakPtr<base::CancelableCallback<void __cdecl(void)> > >,void __cdecl(void)>::RunImpl<void (__cdecl base::CancelableC [0x0000000016607ADC+76]
        base::internal::Invoker<base::internal::BindState<void (__cdecl base::CancelableCallback<void __cdecl(void)>::*)(void)const __ptr64,base::WeakPtr<base::CancelableCallback<void __cdecl(void)> > >,void __cdecl(void)>::Run [0x000000001660E553+51]
        base::Callback<void __cdecl(void),0,0>::Run [0x00000000009DDB90+64]
        base::debug::TaskAnnotator::RunTask [0x0000000000A6C276+758]

I tried this today and it seems to work well. chrome://gpu showed that it uses SwiftShader, and webglsamples.org/aquarium/aquarium.html renders fine. Are you still able to repro the issue?

Let's see -- I've kicked off another try job: https://chromium-review.googlesource.com/543481

Looks like it's still failing the same way:

https://chromium-swarm.appspot.com/task?id=36e524368b223710&refresh=10&show_raw=1

I can replicate it by running the swarming task, but not when running my local build of headless_browsertests, with the same GN args and command line arguments. Any ideas what might still be different between them?

Hmm, having the same GN args should really trigger it. As a data point I was able to see the bug on my local windows machine a couple of weeks ago by doing that. Sadly I never got the chance to debug things further.

Never mind, I synced and rebuilt and I can repro it now. I'll take a closer look at why it asserts.

I had a look at this last week and found that GLRenderer::DrawContentQuadNoAA() is using a ResourceProvider::Resource that has 0 as the GL texture target. This resource is constructed with a SharedBitmapId. So apparently compositing with those is not expected to happen.

CC'ing a few people who might know how we can end up in this situation and why it would only affect Windows.

SharedBitmapId is used in software compositing. We're not using GL contexts at all in that case, swiftshader or not.

It sounds like the browser process thinks it's using GL compositing (via swiftshader or not) but the renderer process thinkgs it's using software compositing. That would be a bug.

Thanks Dana, that explains a lot. Note that since SwiftShader's integration in M59, we can actually use it in two modes:
--use-gl=swiftshader-webgl is intended to use SwiftShader as a WebGL fallback, and disables any other use of the GPU (including GL compositing). It's triggered automatically when the GPU is blacklisted for WebGL.
--use-gl=swiftshader causes us to treat SwiftShader as the GPU. So compositing can happen with the GL path in this case. It's currently only supported as an explicit command-line option and not meant for end users though.

Sami's patch intends to use the former: https://chromium-review.googlesource.com/c/543481

But it looks like that command line flag might be added after the compositor already decided to use the GL path. Is there a difference in GPU process startup order between Linux and Windows? I know blacklisting works differently but I'm not familiar with the details.

Can we get an update if this issue have been fixed which blocks https://bugs.chromium.org/p/chromium/issues/detail?id=737678

Thanks and Regards
Debanjan-B

As of this cl:
https://chromium-review.googlesource.com/c/chromium/src/+/1161172

skyostil@: Headless mode always uses SwiftShader on the trybots. Can this issue be closed or does it involve anything else?

Yes, I believe this should be working now. Thanks!