New issue
Advanced search Search tips

Issue 888087 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug



Sign in to add a comment

Check failed: it != button_margins_.end()

Project Member Reported by xidac...@chromium.org, Sep 21

Issue description

I found that recently whenever I launch chrome, I hit this DCHECK

FATAL:nav_button_provider_gtk.cc(405)] Check failed: it != button_margins_.end()

I did bisect locally and got this:
592969--good
592970--bad

thomasanderson@: could you take a look? It is a bit frustrating that it crashes every time when launching chrome.
 
Status: Assigned (was: Untriaged)
Can we revert the CL in the meantime? I applied the revert (https://chromium-review.googlesource.com/c/chromium/src/+/1239355) to my local build, and it stopped hitting the DCHECK.
Feel free to revert.  Though I cannot reproduce the issue, so you'll have to help me with getting my system configured to reproduce
thomasanderson@: Is your OS linux and with dcheck_always_on = true as one of your gn args?
Sure, let me know what I can help with. 
Stack trace:

[251314:251314:0921/132602.602613:FATAL:nav_button_provider_gtk.cc(408)] Check failed: it != button_margins_.end(). 
#0 0x7f0603d4b15d base::debug::StackTrace::StackTrace()
#1 0x7f0603a529ac base::debug::StackTrace::StackTrace()
#2 0x7f0603ac247a logging::LogMessage::~LogMessage()
#3 0x7f05ede97038 libgtkui::NavButtonProviderGtk::GetNavButtonMargin()
#4 0x5638396f8e02 DesktopLinuxBrowserFrameViewLayout::CaptionButtonY()
#5 0x5638396f62d6 OpaqueBrowserFrameViewLayout::SetBoundsForButton()
#6 0x5638396f5938 OpaqueBrowserFrameViewLayout::ConfigureButton()
#7 0x5638396f559b OpaqueBrowserFrameViewLayout::LayoutWindowControls()
#8 0x5638396f7326 OpaqueBrowserFrameViewLayout::Layout()
#9 0x7f05f014c6bc views::View::Layout()
#10 0x7f05f01825e1 views::NonClientView::LayoutFrameView()
#11 0x7f05f01827cc views::NonClientView::Layout()
#12 0x7f05f0149b51 views::View::SetBoundsRect()
#13 0x7f05f0126045 views::FillLayout::Layout()
#14 0x7f05f014c6bc views::View::Layout()
#15 0x7f05f01d94c6 views::DesktopWindowTreeHostX11::Relayout()
#16 0x7f05f01dc449 views::DesktopWindowTreeHostX11::OnWMStateUpdated()
#17 0x7f05f01de33e views::DesktopWindowTreeHostX11::DispatchEvent()
#18 0x7f06019b4a14 ui::PlatformEventSource::DispatchEvent()
#19 0x7f05ef094a51 ui::X11EventSourceGlib::ProcessXEvent()
#20 0x7f05ef083d85 ui::X11EventSource::ExtractCookieDataDispatchEvent()
#21 0x7f05ef083cf4 ui::X11EventSource::DispatchXEvents()
#22 0x7f05ef094ef5 ui::(anonymous namespace)::XSourceDispatch()
#23 0x7f05dad75e35 g_main_context_dispatch
#24 0x7f05dad76200 <unknown>
#25 0x7f05dad7628c g_main_context_iteration
#26 0x7f0603aedc0f base::MessagePumpGlib::Run()
#27 0x7f0603ae571b base::MessageLoop::Run()
#28 0x7f0603b8e42d base::RunLoop::Run()
#29 0x563834e522b3 ChromeBrowserMainParts::MainMessageLoopRun()
#30 0x7f05fce9bd01 content::BrowserMainLoop::RunMainMessageLoopParts()
#31 0x7f05fcea3f10 content::BrowserMainRunnerImpl::Run()
#32 0x7f05fce8eb70 content::BrowserMain()
#33 0x7f05fed53d94 content::RunBrowserProcessMain()
#34 0x7f05fed5667b content::ContentMainRunnerImpl::Run()
#35 0x7f05fed4b57c content::ContentServiceManagerMainDelegate::RunEmbedderProcess()
#36 0x7f0603ff67fa service_manager::Main()
#37 0x7f05fed517d3 content::ContentMain()
#38 0x563832f44246 ChromeMain
#39 0x563832f44152 main
#40 0x7f05d8bf32b1 __libc_start_main
#41 0x563832f4402a _start

I can repro it 100% on Linux (with the above stack trace). In gn args, I have: is_debug=true.
Project Member

Comment 10 by bugdroid1@chromium.org, Sep 21

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

commit 1a58d4ea4163afd30e85b7784223595a4766e512
Author: Tarun Bansal <tbansal@chromium.org>
Date: Fri Sep 21 21:11:49 2018

Revert "[X11] Don't clear WM state bits when a window is unmapped"

This reverts commit d4d1506d47713470d7b3acad4da9a7f3181fbae0.

Reason for revert: Hitting the DCHECK on Chromium startup.  crbug.com/888087 

Original change's description:
> [X11] Don't clear WM state bits when a window is unmapped
>
> _NET_WM_STATE holds the window state which may be eg: maximized, fullscreen,
> minimized, etc.  In shutdown, Chrome queries this state so that it can restore
> browser windows to the correct state on the next launch.  The problem is that
> Chrome queries this state (hundreds of times, in fact) after the window has
> already gone away.  The EWMH spec requires window managers to delete the
> _NET_WM_STATE property when a window is unmapped [1], so the state that Chrome
> was getting was invalid.
>
> This CL saves the state when a window becomes unmapped, and includes some small
> cleanups.
>
> [1] https://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317598336
>
> BUG= 882258 
> R=​sky
>
> Change-Id: Iacc43563cd54ade77ac83a580ed24434b6802c91
> Reviewed-on: https://chromium-review.googlesource.com/1226645
> Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
> Reviewed-by: Scott Violet <sky@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#592570}

TBR=sky@chromium.org,thomasanderson@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  882258 , 888087 
Change-Id: Iac2776b33ec366235e233878dcdbfd8530e2ea0b
Reviewed-on: https://chromium-review.googlesource.com/1239355
Commit-Queue: Tarun Bansal <tbansal@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Thomas Anderson <thomasanderson@chromium.org>
Reviewed-by: Tarun Bansal <tbansal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593331}
[modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/chrome/browser/ui/libgtkui/gtk_ui.cc
[modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.cc
[modify] https://crrev.com/1a58d4ea4163afd30e85b7784223595a4766e512/ui/views/widget/desktop_aura/desktop_window_tree_host_x11.h

Status: Fixed (was: Assigned)
Marking this issue as fixed after the revert.

Sign in to add a comment