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

Issue 592129 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug



Sign in to add a comment

Chrome crash running with mash_shell on Linux

Project Member Reported by msw@chromium.org, Mar 4 2016

Issue description

Chrome crash running with mash_shell on Linux

On ToT@33407f13bfd05bc2614fd063bcbc6ad38904ad24 Linux Desktop build with target_os = "chromeos"

Running "chrome --mash", I get an infinite loop of:
[ERROR:mash_runner.cc(68)] request to create additional app mojo:desktop_wm
[WARNING:message_queue.cc(38)] Leaking 3 ports in unreceived messages
[ERROR:mash_runner.cc(68)] request to create additional app mojo:ash_sysui
[WARNING:message_queue.cc(38)] Leaking 3 ports in unreceived messages
[ERROR:mash_runner.cc(68)] request to create additional app mojo:quick_launch
[WARNING:message_queue.cc(38)] Leaking 3 ports in unreceived messages
(these are run via StartRestartableService, so they're likely crashing and restarting)

Running "mojo_runner mojo:mash_shell" (maybe + "exe:chrome") I get the shell sans chrome and this callstack:
[9379:9382:0100/000000:FATAL:message_pump_libevent.cc(140)] Check failed: fd >= 0 (-1 vs. 0)
#0 0x7fca1c3fb20e base::debug::StackTrace::StackTrace()
#1 0x7fca1c450b4c <unknown>
#2 0x7fca1c47e826 <unknown>
#3 0x7fca1c46cbc8 base::MessageLoopForIO::WatchFileDescriptor()
#4 0x7fca14a5d40c mojo::edk::(anonymous namespace)::ChannelPosix::StartOnIOThread()
#5 0x7fca14a5bd2d mojo::edk::(anonymous namespace)::ChannelPosix::Start()
#6 0x7fca14a818fb mojo::edk::NodeChannel::Start()
#7 0x7fca14a865a9 mojo::edk::NodeController::ConnectToParentOnIOThread()
#8 0x7fca14a9306e _ZN4base8internal15RunnableAdapterIMN4mojo3edk14NodeControllerEFvNS3_20ScopedPlatformHandleEEE3RunIJS5_EEEvPS4_DpOT_
#9 0x7fca14a92f91 _ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIMN4mojo3edk14NodeControllerEFvNS4_20ScopedPlatformHandleEEEEE8MakeItSoIJPS5_S6_EEEvS9_DpOT_
#10 0x7fca14a92f3d _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0ELm1EEEENS0_9BindStateINS0_15RunnableAdapterIMN4mojo3edk14NodeControllerEFvNS7_20ScopedPlatformHandleEEEEFvPS8_S9_EJNS0_17UnretainedWrapperIS8_EENS0_13PassedWrapperIS9_EEEEENS0_12InvokeHelperILb0EvSC_EEFvvEE3RunEPNS0_13BindStateBaseE
#11 0x7fca1c3df3ce base::Callback<>::Run()
#12 0x7fca1c4009be base::debug::TaskAnnotator::RunTask()
#13 0x7fca1c46c227 base::MessageLoop::RunTask()
#14 0x7fca1c46c498 base::MessageLoop::DeferOrRunPendingTask()
#15 0x7fca1c46c662 base::MessageLoop::DoWork()
#16 0x7fca1c47f20c <unknown>
#17 0x7fca1c46bcba <unknown>
#18 0x7fca1c4f3f84 <unknown>
#19 0x7fca1c46afb1 <unknown>
#20 0x7fca1c560d59 <unknown>
#21 0x7fca1c56108d base::Thread::ThreadMain()
#22 0x7fca1c54e76a <unknown>
#23 0x7fca086c7182 start_thread
#24 0x7fca083f347d clone

Reverting https://codereview.chromium.org/1747053003 avoids the crash(?), but Chrome doesn't appear.
Ken, can you take a look? Sorry if this isn't related to your CL. Thanks!
 
Cc: amistry@chromium.org
If this is happening on chromeos builds only, might be worth trying to revert https://codereview.chromium.org/1759033002 instead.
(locally, that is)

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

I did try reverting that separately, but it didn't seem to avoid the crash.
I'll play around some more with testing the reverts; I don't have a ToT win build atm.
Alright, I can take a look a bit later.

On Fri, Mar 4, 2016 at 2:40 PM, msw@chromium.org via Monorail <
monorail@chromium.org> wrote:

Comment 5 by msw@chromium.org, Mar 4 2016

Hmm, maybe reverting your CL only hides the callstack for mojo_runner, and chrome --mash still loops crashing.... :-/
Reverting amistry@'s CL doesn't seem to affect the crash or callstack reporting.
As far as I can tell, running chrome --mash results in ContentMain never running in any process.

I see browser_driver.mojo and tracing.mojo start up, and then the endless spam. I suspect the bug is somewhere in mash shell or the mojo shell layer.
btw the stack trace looks like potentially like someone trying to use mojo IPC before InitIPCSupport is called. not 100% sure though
Oh, and locally, I don't see the stack trace ever...
Cc: roc...@chromium.org sky@chromium.org ben@chromium.org
Owner: ----
Status: Available (was: Assigned)
As far as I can tell, either the Shell is doing something wrong or the expectations in DefaultShellClient are wrong. Probably related to recent ShellClientFactory changes?

Pipes seem to be working as intended, and any changes to Mojo in Chrome at or below the content layer are irrelevant since that code path is never reached.

Comment 10 by sky@chromium.org, Mar 7 2016

Owner: ben@chromium.org
Status: Started (was: Available)
Ben is looking into the fix.

Comment 11 by sky@chromium.org, Mar 7 2016

The following diff fixes things:

diff --git a/mojo/shell/shell.cc b/mojo/shell/shell.cc
index c6e0a43..5d8a29a 100644
--- a/mojo/shell/shell.cc
+++ b/mojo/shell/shell.cc
@@ -489,8 +489,8 @@ void Shell::OnGotResolvedName(scoped_ptr<ConnectParams> params,
                               mojom::CapabilityFilterPtr base_filter,
                               const String& file_url) {
   std::string qualifier = params->target().qualifier();
-  if (qualifier == GetNamePath(params->target().name()))
-    qualifier = resolved_qualifier;
+  //if (qualifier == GetNamePath(params->target().name()))
+  //  qualifier = resolved_qualifier;
   Identity target(params->target().name(), qualifier,
                   params->target().user_id());
   params->set_target(target);
@@ -523,7 +523,7 @@ void Shell::OnGotResolvedName(scoped_ptr<ConnectParams> params,
     // from the original request rather than for the package itself, which will
     // always be the same.
     CreateShellClient(
-        source, Identity(resolved_name, resolved_qualifier, target.user_id()),
+        source, Identity(resolved_name, target.qualifier(), target.user_id()),
         target.name(), std::move(request));
   } else {
     bool start_sandboxed = false;

Comment 12 by sky@chromium.org, Mar 8 2016

Status: Fixed (was: Started)
Ben fixed this with patchset https://codereview.chromium.org/1775793002/ at 
https://crrev.com/8629ce72e06a8e4dae428f0fbc3ba83cc5555407
Cr-Commit-Position: refs/heads/master@{#379834}
Components: -MUS Internals>Services>WindowService

Sign in to add a comment