New issue
Advanced search Search tips

Issue 707935 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Chrome
Pri: 1
Type: Bug-Regression

Blocking:
issue 653916



Sign in to add a comment

Crash in device::UsbDeviceHandleUsbfs::FileThreadHelper::Start()

Project Member Reported by reillyg@chromium.org, Apr 3 2017

Issue description

On Chrome startup I hit the following crash because the FILE thread has been replaced with a task scheduler thread that does not have a MessageLoop.

device::UsbDeviceHandleUsbfs::FileThreadHelper is a MessageLoop::DestructionObserver so that it can perform cleanup operations before thread exit. We could avoid using the observer if it was possible to post a shutdown blocking task to the thread before it exits.

Received signal 11 SEGV_MAPERR 0000000000a8
#0 0x7faa3f3d7a91 __interceptor_backtrace
#1 0x7faa3d93149c base::debug::StackTrace::StackTrace()
#2 0x7faa3d93049c base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7faa24c35330 <unknown>
#4 0x7faa3d9ab612 base::MessageLoop::AddDestructionObserver()
#5 0x7faa41a68a62 device::UsbDeviceHandleUsbfs::FileThreadHelper::Start()
#6 0x7faa41a76e12 _ZN4base8internal7InvokerINS0_9BindStateIPFvNSt3__110unique_ptrIN6device20UsbDeviceHandleUsbfs16FileThreadHelperENS3_14default_deleteIS7_EEEEEJNS0_13PassedWrapperISA_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#7 0x7faa3d933cb9 base::debug::TaskAnnotator::RunTask()
#8 0x7faa3daaac7d base::internal::TaskTracker::PerformRunTask()
#9 0x7faa3daab32c base::internal::TaskTrackerPosix::PerformRunTask()
#10 0x7faa3daa97c7 base::internal::TaskTracker::RunTask()
#11 0x7faa3da98c0b base::internal::SchedulerWorker::Thread::ThreadMain()
#12 0x7faa3dac5625 base::(anonymous namespace)::ThreadFunc()
#13 0x7faa24c2d184 start_thread
#14 0x7faa24743bed clone
  r8: 0000000000000015  r9: 0000000000000000 r10: 0000000000003fff r11: 00000000000000b0
 r12: 0000604000764150 r13: 00000ff53de82a08 r14: 00007fa9ef415040 r15: 0000000000000016
  di: 00000000000000a8  si: 00007fa9ef415060  bp: 00007fa9f07106b0  bx: 00007fa9f0710640
  dx: 0000000000000000  ax: 00007fa9ef415040  cx: 00000ff53de82a0c  sp: 00007fa9f0710640
  ip: 00007faa3d9ab612 efl: 0000000000010246 cgf: 0000000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 00000000000000a8
[end of stack trace]
 
Components: Internals>TaskScheduler
Labels: ReleaseBlock-Dev
 http://crbug.com/650318  - Remove MessageLoop destruction observers

Looks like we've got one here.
Labels: -ReleaseBlock-Dev ReleaseBlock-Beta M-58
Status: Assigned (was: Untriaged)
This is causing crashes on M-58 and M-59 e.g., 3349df9c10000000 and 280afa6ee0000000. Can we get this variation rolled back?
Labels: Stability-Crash
That's strange. The variation should only be applying to Dev and Canary.
Yup, very strange.

3349df9c10000000 (58.0.3029.14) has BrowserScheduler: RedirectAll8
Labels: -ReleaseBlock-Beta ReleaseBlock-Dev
Figured out the beta strangeness. The builds referenced in the crash, while M58 are actually old M58 builds. The channel is reported as dev in the crash.

Readjusting to ReleaseBlock-Dev.
The variation has been rolled back and should be making its way through.
Project Member

Comment 9 by sheriffbot@chromium.org, Apr 4 2017

Labels: FoundIn-M-59 Fracas
Users experienced this crash on the following builds:

Linux Dev 59.0.3053.3 -  0.48 CPM, 2 reports, 2 clients (signature base::ObserverListBase<AboutSigninInternals::Observer>::AddObserver)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas
Cc: ligim...@chromium.org
Labels: -ReleaseBlock-Dev ReleaseBlock-Stable
From #6 , this crash was reported in older chrome version, currently we have 	58.0.3029.41 in production. Please confirm whether its still reproducible in latest beta and canary.

Crash rate is pretty low and majority of the reports are from cros, moving to RB Stable.

OS
===
Chrome_ChromeOS	95.62%	240	
Chrome_Linux	4.38%	11	

Link to the builds which introduced the crash.
===============================================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3AObserverListBase%3CAboutSigninInternals%3A%3AObserver%3E%3A%3AAddObserver%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000,magicsignature

Comment 11 by gab@chromium.org, Apr 4 2017

Labels: -ReleaseBlock-Stable -M-58 M-59
Owner: gab@chromium.org
Not release blocking, this is an experiment on Canary/Dev (merely hit M58 users on Dev).
Blocking: 653916
Cc: reillyg@chromium.org
Status: Fixed (was: Assigned)
Propagating change info. This has been addressed:

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

commit 56564d4099ebbaecf1cfb804cc09a6d198101fbb
Author: reillyg <reillyg@chromium.org>
Date: Wed Apr 05 02:59:17 2017

Remove MessageLoop destruction observer from //device/usb

This patch updates UsbDeviceHandleUsbfs::FileThreadHelper to no longer
be a MessageLoop::DestructionObserver and instead ensures that
UsbService::ShutDown will close all open connections, destroying the
FILE thread state.

BUG=  650723  

Review-Url: https://codereview.chromium.org/2797433005
Cr-Commit-Position: refs/heads/master@{#461960}

[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_android.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_usbfs.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_device_handle_usbfs.h
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_service.cc
[modify] https://crrev.com/56564d4099ebbaecf1cfb804cc09a6d198101fbb/device/usb/usb_service_unittest.cc

Sign in to add a comment