Predator and CL did not provide any possible suspects.
Using Code Search for the file, "midi_manager_alsa.cc assigning to the related owner.

@toyoshim -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

I understand the problem and have a fix now.


- What happens around MidiService <-> Chrome browser process interface.

1. MidiService::Shutdown() is called on the main thread
2. MidiService::EndSession() is called on the I/O thread


- What happens inside MidiService and MidiManager

1. MidiService::Shutdown() calls MidiManager::Shutdown() that post MidiManager::ShutdownOnSessionThread() to the I/O thread
2. MidiService::EndSession() notices that this is the last session, and call MidiManager::Shutdown() and destruct MidiManager instance. This second MidiManager::Shutdown() does nothing but just set |finalized_| to true.
3. The destructor call hits CHECK failures in ~MidiManagerAlsa
(If CHECK is not there...)
4. MidiManager::ShutdownOnSessionThread() will be called on the I/O thread, but it's late.


- How to fix

Once MidiService::Shutdown() is called, we should do nothing in EndSession() against MidiManager. Also, Shutdown() should post a task to destruct MidiManager on the I/O thread.


- What happens after the fix

1. MidiService::Shutdown() calls MidiManager::Shutdown() that post MidiManager::ShutdownOnSessionThread() to the I/O thread. Also post MidiService::DestructMidiManager() to the I/O thread.
2. MidiService::EndSession() does nothing because Shutdown() is already called
3. MidiManager::ShutdownOnSessionThread() is called on the I/O thread
4. MidiManager::~MidiManager() is called on the I/O thread
5. MidiService::~MidiService() is called on the main thread

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

commit 04ede5c2102a1983d03cc4ea065b24555b09e0b5
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Mon May 29 07:44:43 2017

Web MIDI: MidiService::EndSession() could be called after Shutdown()

On browser shutdown, EndSession() might be called after Shutdown()
depending on timing.

If the dynamic instantiation mode is enabled, this causes a problem
MidiManager::Shutdown() will be called twice, and the destructor
runs on the main thread before ShutdownOnSessionThread() runs on the
I/O thread.

This does not cause a real problem, but hits an assertion at the
destructor.

This fix disallows to call MidiManager::EndSession() after the Shutdown(),
then calll the destructor on the I/O thread before the MidiService
is destructed.

BUG= 724653 
TEST=midi_unittests
TEST=content_unittests --gtest_filter='Midi*.*'
TEST=clusterfuzz reproduce -c 6107679889293312

Change-Id: I05d081ab555f596b1d9b5801947e4042e01f3f2b
Reviewed-on: https://chromium-review.googlesource.com/515064
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#475306}
[modify] https://crrev.com/04ede5c2102a1983d03cc4ea065b24555b09e0b5/media/midi/midi_service.cc
[modify] https://crrev.com/04ede5c2102a1983d03cc4ea065b24555b09e0b5/media/midi/midi_service.h

A fix was submitted.
I will wait for the fuzz detecting the issue fixed.

ClusterFuzz has detected this issue as fixed in range 474410:474803.

Detailed report: https://clusterfuzz.com/testcase?key=6107679889293312

Fuzzer: inferno_twister
Job Type: linux_ubsan_chrome
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !initialization_thread_checker_ in midi_manager_alsa.cc
  midi::MidiManagerAlsa::~MidiManagerAlsa
  midi::MidiManagerAlsa::~MidiManagerAlsa
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=455091:455389
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_chrome&range=474410:474803

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6107679889293312


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 6107679889293312 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.