Adding screenshot of task manager

Deleted: Screen Shot 2017-11-06 at 11.46.17 AM.png 112 KB

	Screen Shot 2017-11-06 at 11.46.17 AM.png 112 KB View Download

Attaching trace file.

Deleted: trace_trace.json.gz 206 KB

trace_trace.json.gz 206 KB Download

Thank you for the trace.

Attaching screenshot of the top part of activity monitor, sorted by CPU.

Deleted: Screen Shot 2017-11-06 at 12.14.44 PM.png 250 KB

	Screen Shot 2017-11-06 at 12.14.44 PM.png 250 KB View Download

rfoust@: Can you please grab a sample of the hanging process via the Activity.app and attached it here too?

Thank you.

    222 Thread_26668: TaskSchedulerBackgroundBlockingWorker
    + 222 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff64a30c5d]
    +   222 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff64a3156d]
    +     222 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff64a316c1]
    +       222 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bfba27  [platform_thread_posix.cc:77]
    +         222 base::internal::SchedulerWorker::Thread::ThreadMain()  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bebbe8  [scheduler_worker.cc:73]
    +           222 base::internal::TaskTracker::RunNextTask(base::internal::Sequence*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bf0205  [memory:2543]
    +             222 base::internal::TaskTrackerPosix::PerformRunTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bf0ae3  [memory:2543]
    +               222 base::internal::TaskTracker::PerformRunTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bf058b  [task_tracker.cc:335]
    +                 222 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1b854f4  [callback_forward.h:11]
    +                   222 base::(anonymous namespace)::PostTaskAndReplyRelay::RunTaskAndPostReply()  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1bfbbf9  [callback_forward.h:11]
    +                     222 component_updater::DefaultComponentInstaller::StartRegistration(scoped_refptr<component_updater::DefaultComponentInstaller::RegistrationInfo> const&, component_updater::ComponentUpdateService*)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x30fe2dd  [iterator:1359]
    +                       222 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x10d0bb000 + 0x1b941c5  [file_util_posix.cc:234]
    +                         222 unlink  (in libsystem_kernel.dylib) + 11  [0x7fff648f42e0]
    +                           222 __unlink  (in libsystem_kernel.dylib) + 10  [0x7fff648f75f2]

Here's the terminal output when using these arguments: --enable-logging=stderr --v=1

Deleted: debug-output.txt 134 KB

debug-output.txt 134 KB View Download

Here is a sample taken when I try to exit Chrome and it hangs/unresponsive before I force-quit it.

Deleted: Unresponsive sample Google Chrome.txt 103 KB

Unresponsive sample Google Chrome.txt 103 KB View Download

sorin@/waffles@, any thoughts?

Tried the beta, same behavior with:

Version 63.0.3239.30 (Official Build) beta (64-bit)

I don't know what is wrong and I am still investigating.

Comment #7 indicates that the the component updater is running the StartRegistration code as part of PostTaskAndReply invocation. StartRegistration calls DeleteFile toward the end of the function execution to clean up old component files. It looks like that call blocks on unlink, which is expected but I don't understand why it does not return, nor why CPU utilization is high.

Comment #8 shows that the components are registered correctly, and the StartRegistration/FinishRegistration calls in the component updater are interleaved and paired up as expected. There is no evidence I could see about a deadlock on DeleteFile.

Also, I see no evidence of component updater code running in the trace provided by the original post.

Attaching a sample taken of Canary after it downloaded an update but before restarting (since it will likely hang on close anyway).  I noticed a different function under one of the TaskSchedulerBackgroundBlockingWorker sections.  No idea if this is irrelevant or if it helps. Let me know if I can test anything or provide more information. Thanks!

1 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1a3c70b  [0x1127db70b]
    +                     1 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1a3de76  [0x1127dce76]
    +                       1 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1c6a2b0  [0x112a092b0]
    +                         1 readdir$INODE64  (in libsystem_c.dylib) + 35  [0x7fff4f5db6fb]
    +                           1 _readdir_unlocked$INODE64  (in libsystem_c.dylib) + 114  [0x7fff4f5db656]
    +                             1 __getdirentries64  (in libsystem_kernel.dylib) + 10  [0x7fff4f6af6ce]

Deleted: canary-after-update.txt 131 KB

canary-after-update.txt 131 KB View Download

This one looks suspiciously long:

    848 Thread_2339523: UsbEventHandler/149519
    + 848 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff4f7e9c5d]
    +   848 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff4f7ea56d]
    +     848 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff4f7ea6c1]
    +       848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cda617  [0x112a79617]
    +         848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cdf11c  [0x112a7e11c]
    +           848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x370ba39  [0x1144aaa39]
    +             848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719ec2  [0x1144b8ec2]
    +               848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719a95  [0x1144b8a95]
    +                 848 ???  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719d4d  [0x1144b8d4d]
    +                   848 poll  (in libsystem_kernel.dylib) + 10  [0x7fff4f6b14ea]

Is there an external, possibly USB-attached drive that is in use here? There are 3 threads that are taking all of the time. Here they are symbolized:
 
    848 Thread_2339523: UsbEventHandler/149519
    + 848 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff4f7e9c5d]
    +   848 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff4f7ea56d]
    +     848 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff4f7ea6c1]
    +       848 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cda617  [platform_thread_posix.cc:77]
    +         848 base::SimpleThread::ThreadMain()  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cdf11c  [string:1221]
    +           848 device::UsbContext::UsbEventHandler::Run()  (in Google Chrome Framework)  load address 0x110d9f000 + 0x370ba39  [usb_context.cc:49]
    +             848 libusb_handle_events  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719ec2  [io.c:2202]
    +               848 libusb_handle_events_timeout_completed  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719a95  [io.c:2126]
    +                 848 handle_events  (in Google Chrome Framework)  load address 0x110d9f000 + 0x3719d4d  [io.c:1963]
    +                   848 poll  (in libsystem_kernel.dylib) + 10  [0x7fff4f6b14ea]

    848 Thread_2338117: TaskSchedulerBackgroundBlockingWorker
    + 848 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff4f7e9c5d]
    +   848 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff4f7ea56d]
    +     848 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff4f7ea6c1]
    +       848 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cda617  [platform_thread_posix.cc:77]
    +         848 base::internal::SchedulerWorker::Thread::ThreadMain()  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cc95f0  [scoped_refptr.h:174]
    +           848 base::internal::TaskTracker::RunNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cce717  [memory:2543]
    +             848 base::internal::TaskTrackerPosix::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1ccf92c  [memory:2543]
    +               848 base::internal::TaskTracker::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1ccedbc  [task_tracker.cc:411]
    +                 848 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1c6580c  [callback_forward.h:11]
    +                   848 base::(anonymous namespace)::PostTaskAndReplyRelay::RunTaskAndPostReply()  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cda7d9  [callback_forward.h:11]
    +                     848 component_updater::ComponentInstaller::StartRegistration(scoped_refptr<component_updater::ComponentInstaller::RegistrationInfo> const&, component_updater::ComponentUpdateService*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x312f23d  [iterator:1359]
    +                       848 base::DeleteFile(base::FilePath const&, bool)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1c73553  [file_util_posix.cc:274]
    +                         848 unlink  (in libsystem_kernel.dylib) + 11  [0x7fff4f6ad2e0]
    +                           848 __unlink  (in libsystem_kernel.dylib) + 10  [0x7fff4f6b05f2]

    848 Thread_2338107: CrShutdownDetector
    + 848 thread_start  (in libsystem_pthread.dylib) + 13  [0x7fff4f7e9c5d]
    +   848 _pthread_start  (in libsystem_pthread.dylib) + 377  [0x7fff4f7ea56d]
    +     848 _pthread_body  (in libsystem_pthread.dylib) + 340  [0x7fff4f7ea6c1]
    +       848 base::(anonymous namespace)::ThreadFunc(void*)  (in Google Chrome Framework)  load address 0x110d9f000 + 0x1cda617  [platform_thread_posix.cc:77]
    +         848 (anonymous namespace)::ShutdownDetector::ThreadMain()  (in Google Chrome Framework)  load address 0x110d9f000 + 0xf0497f  [shutdown_signal_handlers_posix.cc:133]
    +           848 read  (in libsystem_kernel.dylib) + 10  [0x7fff4f6b1592]

@ rfoust: Could you please respond to C#17

Thanks !!

The only USB device I have is a Yubikey. I unplugged it but didn't make a difference.

So I tried loading Firefox, which apparently hangs at load and it seems to be hanging on an unlink call as well.  So then I tried creating a new login account/profile, and both chrome and firefox work fine in the new profile.

I guess it seems to be something hosed up in my profile? No idea what though.  Since it is happening in more than one app, sounds like it may not really be a Chrome bug. I think I'm at a point where I probably just need to limp along until I can reinstall the OS from scratch and start over. :) 

I understand if you want to close this issue, but if you want me to try anything else, feel free to let me know.  Thanks again for all the assistance with this.

Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I will close this for now. At any rate, it is unlikely that the component updater in Chrome is causing this. Thank you for reporting it.

 Issue 793805  has been merged into this issue.