New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 591908 link

Starred by 1 user
Status: WontFix
Owner:
█ ben@chromium.org
Last visit > 30 days ago
Closed: Aug 2016
Cc:
jbroman@chromium.org
jonr...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Crash in mojo when running chrome without clobber build

Project Member Reported by flackr@chromium.org, Mar 4 2016 
chrome started crashing - I bisected to this commit: https://chromium.googlesource.com/chromium/src/+/3c7823a6bbdcb75f8762f1c6b787ae67a6eaec6e

I am building only the chrome and blink_tests targets and both chrome and run-webkit-tests crash with the following stack trace:
[855:855:0303/224725:FATAL:package_manager.cc(44)] Check failed: mojo::IsValidName(name_string). Invalid Name: Package Manager
#0 0x7f5b98750cbe base::debug::StackTrace::StackTrace()
#1 0x7f5b9876b59b logging::LogMessage::~LogMessage()
#2 0x7f5b9536c171 package_manager::(anonymous namespace)::BuildApplicationInfoFromDictionary()
#3 0x7f5b9536c9f9 package_manager::PackageManager::DeserializeApplication()
#4 0x7f5b9536d073 package_manager::PackageManager::OnReadManifestImpl()
#5 0x7f5b9536be80 package_manager::PackageManager::OnReadManifest()
#6 0x7f5b9536f713 _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1ELm2ELm3EEEENS0_9BindStateINS0_15RunnableAdapterIPFvNS_7WeakPtrIN15package_manager14PackageManagerEEERKSsSB_RKN4mojo8CallbackIFvNSC_6StringESE_NSC_9StructPtrINSC_5shell5mojom16CapabilityFilterEEESE_EEE10scoped_ptrINS_5ValueESt14default_deleteISP_EEEEEST_JS9_SB_SB_SN_EEENS0_12InvokeHelperILb0EvSV_EEFvSS_EE3RunEPNS0_13BindStateBaseESS_
#7 0x7f5b95027545 base::internal::ReplyAdapter<>()
#8 0x7f5b987b50c4 base::(anonymous namespace)::PostTaskAndReplyRelay::RunReplyAndSelfDestruct()
#9 0x7f5b98751e2c base::debug::TaskAnnotator::RunTask()
#10 0x7f5b9877196b base::MessageLoop::RunTask()
#11 0x7f5b98771c78 base::MessageLoop::DeferOrRunPendingTask()
#12 0x7f5b98771e9b base::MessageLoop::DoWork()
#13 0x7f5b9877381a base::(anonymous namespace)::WorkSourceDispatch()
#14 0x7f5b90fb7e04 g_main_context_dispatch
#15 0x7f5b90fb8048 <unknown>
#16 0x7f5b90fb80ec g_main_context_iteration
#17 0x7f5b98773676 base::MessagePumpGlib::Run()
#18 0x7f5b98793820 base::RunLoop::Run()
#19 0x7f5b98d6d99d ChromeBrowserMainParts::MainMessageLoopRun()
#20 0x7f5b9502c068 content::BrowserMainLoop::RunMainMessageLoopParts()
#21 0x7f5b9502ee2d content::BrowserMainRunnerImpl::Run()
#22 0x7f5b9502788c content::BrowserMain()
#23 0x7f5b95807222 content::ContentMainRunnerImpl::Run()
#24 0x7f5b95805fb0 content::ContentMain()
#25 0x7f5b98d33afa ChromeMain
#26 0x7f5b8e18cec5 __libc_start_main
#27 0x7f5b98d339d1 <unknown>

Everything works after running gn clean and rebuilding, so maybe a build rule is missing?

Comment 1 by ben@chromium.org, Mar 4 2016 

Hrm

I changed the key names for some properties in the mojo package manifest, renaming "url" to "name" and "name" to "display_name".

The error logged shows the new parsing code believing the "name" field is set to "Package Manager" which should be in the "display_name" slot. This makes me think the manifest.json in your outdir was stale.

There was a bug a week or two ago about the manifests not being regenerated when the source file changed, but I fixed that. I'm curious if you see this again.

Comment 2 by jonr...@chromium.org, Mar 4 2016 

I have the commit referenced in #1

Using the same args as flackr@ I can build/run chrome from an empty directory
    clang_use_chrome_plugins = true 
    is_component_build = true 
    is_debug = false 
    use_goma = true

It may be incorrectly updating manifests

Comment 3 by flackr@chromium.org, Mar 4 2016 

Right, a clean build works. I haven't dug into how far back you'd have to go, but I think that if you do a build from a revision on Sun Feb 28th, and then checkout past the commit in #1 and try to build without cleaning, that you may be able to reproduce the error.

Comment 4 by ben@chromium.org, Aug 16 2016

Status: WontFix (was: Untriaged)
I bet this is fixed by now. The class names are all different anyway so if this reoccurs file again.
►

Sign in to add a comment