54.0.2788.0 (Developer Build) (64-bit) Debug build, Linux

Similar issue occurred to me when I was trying to fix  issue 532233 .

Steps to reproduce:
1. Open incognito window
2. Go to https://jsfiddle.net/6k7otufq/9/
3. Move mouse to the blue box and stay

What do you see instead?

browser crash

[6716:6716:0705/143607:FATAL:x11_util.cc(339)] Check failed: cursor_image->colorType() == kN32_SkColorType. 
#0 0x7f2fbb25c25e base::debug::StackTrace::StackTrace()
#1 0x7f2fbb2bee5f logging::LogMessage::~LogMessage()
#2 0x7f2faeb26b15 ui::SkBitmapToXcursorImage()
#3 0x7f2fb68551e0 content::WebCursor::GetPlatformCursor()
#4 0x7f2fb6854e56 content::WebCursor::GetNativeCursor()
#5 0x7f2fb6213da6 content::RenderWidgetHostViewAura::UpdateCursorIfOverSelf()
#6 0x7f2fb6213b24 content::RenderWidgetHostViewAura::UpdateCursor()
#7 0x7f2fb61eebbc content::RenderWidgetHostImpl::SetCursor()
#8 0x7f2fb61ea532 content::RenderWidgetHostImpl::OnSetCursor()
#9 0x7f2fb61fca69 _ZN4base20DispatchToMethodImplIPN7content20RenderWidgetHostImplEMS2_FvRKNS1_9WebCursorEEJS4_EJLm0EEEEvRKT_T0_RKSt5tupleIJDpT1_EENS_13IndexSequenceIJXspT2_EEEE
#10 0x7f2fb61fc9c5 _ZN4base16DispatchToMethodIPN7content20RenderWidgetHostImplEMS2_FvRKNS1_9WebCursorEEJS4_EEEvRKT_T0_RKSt5tupleIJDpT1_EE
#11 0x7f2fb61fc90f _ZN3IPC16DispatchToMethodIN7content20RenderWidgetHostImplEMS2_FvRKNS1_9WebCursorEEvSt5tupleIJS3_EEEEvPT_T0_PT1_RKT2_
#12 0x7f2fb61f4ba7 _ZN3IPC8MessageTI26ViewHostMsg_SetCursor_MetaSt5tupleIJN7content9WebCursorEEEvE8DispatchINS3_20RenderWidgetHostImplES8_vMS8_FvRKS4_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#13 0x7f2fb61e88cc content::RenderWidgetHostImpl::OnMessageReceived()
#14 0x7f2fb61a53a3 content::RenderProcessHostImpl::OnMessageReceived()
#15 0x7f2fb33695b8 IPC::ChannelProxy::Context::OnDispatchMessage()
#16 0x7f2fb336dd9b _ZN4base8internal13FunctorTraitsIMN3IPC12ChannelProxy7ContextEFvRKNS2_7MessageEEE6InvokeIRK13scoped_refptrIS4_EJS7_EEEvS9_OT_DpOT0_
#17 0x7f2fb336dc96 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN3IPC12ChannelProxy7ContextEFvRKNS4_7MessageEEJRK13scoped_refptrIS6_ES9_EEEvOT_DpOT0_
#18 0x7f2fb336dc23 _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE7RunImplIRKSA_RKSt5tupleIJSC_S6_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#19 0x7f2fb336d93c _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#20 0x7f2fbb24306e base::Callback<>::Run()
#21 0x7f2fbb2619ee base::debug::TaskAnnotator::RunTask()
#22 0x7f2fbb2dc1bc base::MessageLoop::RunTask()
#23 0x7f2fbb2dc458 base::MessageLoop::DeferOrRunPendingTask()
#24 0x7f2fbb2dc6b2 base::MessageLoop::DoWork()
#25 0x7f2fbb2233bc base::MessagePumpGlib::HandleDispatch()
#26 0x7f2fbb223b81 base::(anonymous namespace)::WorkSourceDispatch()
#27 0x7f2faa516e04 g_main_context_dispatch
#28 0x7f2faa517048 <unknown>
#29 0x7f2faa5170ec g_main_context_iteration
#30 0x7f2fbb2234bf base::MessagePumpGlib::Run()
#31 0x7f2fbb2dbbaf base::MessageLoop::RunHandler()
#32 0x7f2fbb36c534 base::RunLoop::Run()
#33 0x7f2fbc64d2df ChromeBrowserMainParts::MainMessageLoopRun()
#34 0x7f2fb5953e09 content::BrowserMainLoop::RunMainMessageLoopParts()
#35 0x7f2fb595eb25 content::BrowserMainRunnerImpl::Run()
#36 0x7f2fb594dee6 content::BrowserMain()
#37 0x7f2fb5725c86 content::RunNamedProcessTypeMain()
#38 0x7f2fb5728c72 content::ContentMainRunnerImpl::Run()
#39 0x7f2fb5724c52 content::ContentMain()
#40 0x7f2fbbdabb02 ChromeMain
#41 0x7f2fbbdabab2 main
#42 0x7f2fa77fef45 __libc_start_main
#43 0x7f2fbbdab9b5 <unknown>

Aborted (core dumped)

did we change anything in this area recently?

I've been touching native widget code, so will at least try to reproduce and triage.

The test in c#1 is using .ico images, so this may be related to the recent lazy-ico work (https://codereview.chromium.org/2044093002).

c#1 reproduces cleanly and easily. In the debugger, at the time of the crash we're seeing a cursor_image that is completely zeroed out, so colorType is unknown instead of the N32 we expect. After a few cursors fail to load, we stop crashing. It doesn't *consistently* reproduce when I have low-level breakpoints in the debugger, suggesting another thread at work - more evidence that it's lazy decoding?

This seems to be a debug-only "problem": we get warnings out of the X server, but we properly load a custom cursor, perhaps after a few frames of delay.

scroggo@ is out, so adding msarett@. Leaving it at priority 3; we don't expect to further diagnose or fix it any time soon.

Thanks for the diagnose! Since it's debug-only I will just go ahead and ignore this issue.

Why are we ignoring this because it's debug-only? This impacts my workflow because I have to comment out the DCHECK during development (I run with DCHECKs on.... because that is the point of DCHECKs).

Can we remove the DCHECK if we are just ignoring it?

 Issue 640695  has been merged into this issue.

My comment 7 was probably too inflammatory, sorry. I realized now that comment 6 is from a reporter of this bug, not someone who was assigned to it.

However I indeed feel frustrated by the amount of DCHECKs that fail when running Chrome. I hit this going to a maps link, like the original bug report.

Perhaps if this is a bad DCHECK (i.e. it is possible for it to fail), we should just temporarily remove it?

This is also impacting my work, as I am consistently hitting this DCHECK while investigating another issue.

That is fine with me.  I'm not aware that anyone is actively investigating this bug.

Sounds good to me, I can upload a patch with a todo referencing this bug.

Thanks.  Marking this bug as available.

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

commit 2cf716e4b8cecd7600fa3740a28fedb5269ab195
Author: csharrison <csharrison@chromium.org>
Date: Mon Feb 20 23:30:25 2017

Remove bad DCHECK in SkBitmapToXcursorImage

This DCHECK can be triggered in the code, but it doesn't cause any
major problems in production. This patch removes it in favor of a TODO.

BUG= 596782 

Review-Url: https://codereview.chromium.org/2686163002
Cr-Commit-Position: refs/heads/master@{#451671}

[modify] https://crrev.com/2cf716e4b8cecd7600fa3740a28fedb5269ab195/ui/base/x/x11_util.cc

I believe this is fixed with #14, so closing this out.

Let's keep it open. The code that landed includes a TODO referencing this bug. The underlying issue should still be investigated and fixed, and the DCHECK re-added if possible.

Un-cc-ing me from all bugs on my final day.

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!