DCHECK in chromeos=1 build with etherneteap network |
||||
Issue descriptionWhen running a chromeos=1 ToT build locally, a DCHECK is hit each time I try to click on the "Connected to eth1" system menu: [network_icon.cc(640)] Check failed: false. Request for icon for unsupported type: etherneteap #0 0x7fc0f6b8371e base::debug::StackTrace::StackTrace() [84/26790] #1 0x7fc0f6bea61c logging::LogMessage::~LogMessage() #2 0x7fc0e7d750e2 ash::network_icon::(anonymous namespace)::GetIcon() #3 0x7fc0e7d7467a ash::network_icon::(anonymous namespace)::NetworkIconImpl::GenerateImage() #4 0x7fc0e7d711c1 ash::network_icon::(anonymous namespace)::NetworkIconImpl::Update() #5 0x7fc0e7d6e879 ash::network_icon::(anonymous namespace)::FindAndUpdateImageImpl() #6 0x7fc0e7d6e434 ash::network_icon::GetImageForNetwork() #7 0x7fc0e7d847de ash::NetworkListViewMd::UpdateNetworkIcons() #8 0x7fc0e7d843fd ash::NetworkListViewMd::Update() #9 0x7fc0e7d8bd4d ash::tray::NetworkStateListDetailedView::UpdateNetworkList() #10 0x7fc0e7d8bce9 ash::tray::NetworkStateListDetailedView::Update() #11 0x7fc0e7d8c50a ash::tray::NetworkStateListDetailedView::Init() #12 0x7fc0e7d91fed ash::TrayNetwork::CreateDetailedView() #13 0x7fc0e7df5bff ash::SystemTrayBubble::CreateItemViews() #14 0x7fc0e7df573f ash::SystemTrayBubble::UpdateView() #15 0x7fc0e7deca06 ash::SystemTray::ShowItems() #16 0x7fc0e7decece ash::SystemTray::ShowDetailedView() #17 0x7fc0e7e01367 ash::SystemTrayItem::DoTransitionToDetailedView() #18 0x7fc0e7ca8905 _ZN4base8internal13FunctorTraitsIMN3ash21AcceleratorControllerEFvvEvE6InvokeIPS3_JEEEvS5_OT_DpOT0_ #19 0x7fc0e7e01a11 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN3ash14SystemTrayItemEFvvEJPS5_EEEvOT_DpOT0_ #20 0x7fc0e7e019b7 _ZN4base8internal7InvokerINS0_9BindStateIMN3ash14SystemTrayItemEFvvEJNS0_17UnretainedWrapperIS4_EEEEEFvvEE7RunImplIRKS6_RKSt5tupleIJS8_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #21 0x7fc0e7e018fc _ZN4base8internal7InvokerINS0_9BindStateIMN3ash14SystemTrayItemEFvvEJNS0_17UnretainedWrapperIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #22 0x7fc0f6b51fab base::internal::RunMixin<>::Run() #23 0x7fc0f6d5e695 base::Timer::RunScheduledTask() #24 0x7fc0f6d5e779 base::BaseTimerTaskInternal::Run() #25 0x7fc0f6b99645 _ZN4base8internal13FunctorTraitsIMNS_21FileDescriptorWatcher10Controller7WatcherEFvvEvE6InvokeIPS4_JEEEvS6_OT_DpOT0_ #26 0x7fc0f6d5e9c1 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMNS_21BaseTimerTaskInternalEFvvEJPS4_EEEvOT_DpOT0_ #27 0x7fc0f6d5e967 _ZN4base8internal7InvokerINS0_9BindStateIMNS_21BaseTimerTaskInternalEFvvEJNS0_12OwnedWrapperIS3_EEEEEFvvEE7RunImplIRKS5_RKSt5tupleIJS7_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #28 0x7fc0f6d5e8ac _ZN4base8internal7InvokerINS0_9BindStateIMNS_21BaseTimerTaskInternalEFvvEJNS0_12OwnedWrapperIS3_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #29 0x7fc0f6b88cc1 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv #30 0x7fc0f6b886b4 base::debug::TaskAnnotator::RunTask() #31 0x7fc0f6c117cf base::MessageLoop::RunTask() #32 0x7fc0f6c11a34 base::MessageLoop::DeferOrRunPendingTask() #33 0x7fc0f6c11fac base::MessageLoop::DoDelayedWork() #34 0x7fc0f6c273e8 base::MessagePumpGlib::Run() #35 0x7fc0f6c11395 base::MessageLoop::RunHandler() #36 0x7fc0f6cae484 base::RunLoop::Run() #37 0x7fc0f96f2867 ChromeBrowserMainParts::MainMessageLoopRun() #38 0x7fc0f06756b6 content::BrowserMainLoop::RunMainMessageLoopParts() #39 0x7fc0f0680f95 content::BrowserMainRunnerImpl::Run() #40 0x7fc0f066f598 content::BrowserMain() #41 0x7fc0f1cb76a6 content::RunNamedProcessTypeMain() #42 0x7fc0f1cb98d5 content::ContentMainRunnerImpl::Run() #43 0x7fc0f1cb6a72 content::ContentMain() #44 0x7fc0f7b8b4c1 ChromeMain #45 0x7fc0f7b8b3e2 main #46 0x7fc0e0888f45 __libc_start_main #47 0x7fc0f7b8b2e5 <unknown> Steven, CC'ing you as you are probably familiar with the code. I didn't try to find a suspecting CL.
,
Nov 21 2016
I don't think any of our recent changes would have affected this. According to code comments that have been there for at least two years, NetworkTypePattern::Ethernet is supposed to match eap, but I can't see how it would.
,
Nov 21 2016
That comment is incorrect. We should change the comment. If it's a DCHECK I am guessing that we are only seeing this now because with GN it is a lot easier to enable DCHECK with an official build (which is what is required for this to trigger)? It is also possible that before somehow the type was always 'ethernet' and something else has changed to make Google-A be 'ethernet-eap', but that seems unlikely. I will try to look into this a bit further. It would be nice to know whether this is somehow MD only.
,
Nov 21 2016
How are you running chrome? This shouldn't happen actually. kTypeEthernetEap isn't a real type, it is only used for configuring Shill, it should never show up as a network in the network list.
,
Nov 22 2016
I'm building and running it locally as usual (GN args are: target_os="chromeos", use_goma=true, is_debug=true, is_component_build=true): $ out/Default/chrome --user-data-dir=some/path --login-manager
,
Nov 22 2016
I can't produce this with those same args. Is this happening in the login screen, or after login, or both? Can you try reproducing with a fresh user directory? I am wondering if you have some policy setup that we are not handling correctly? There should not be a network in the list with type etherneteap.
,
Nov 22 2016
Currently I'm not able to reproduce this with a fresh profile. Not sure what has changed - maybe something have been fixed in the trunk today. But if you are interested in investigating this, I still keep the old data dir, with which the DCHECK is still hit reliably. Or feel free to close the bug. > Is this happening in the login screen, or after login, or both? Both.
,
Nov 22 2016
Not really that interested in investigating further :-) It's a game implementation anyway.
,
Nov 23 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by steve...@chromium.org
, Nov 21 2016Owner: tdander...@chromium.org
Status: Assigned (was: Untriaged)