Steps to repro:

1) on a debug build, load MR extension with Cast devices on network
2) unload (or reload) MR extension. Note this is also reproducible by running MR integration tests.
3) Get stack trace that looks like the following.

[172163:172163:1104/113042:FATAL:extension_function.cc(469)] Check failed: !browser_client || browser_client->IsShuttingDown() || did_respond() || ignore_all_did_respond_for_testing_do_not_use. cast.channel.open
#0 0x7feb2f44655e base::debug::StackTrace::StackTrace()
#1 0x7feb2f4b5a8f logging::LogMessage::~LogMessage()
#2 0x7feb3052a7ac UIThreadExtensionFunction::~UIThreadExtensionFunction()
#3 0x7feb3052b111 AsyncExtensionFunction::~AsyncExtensionFunction()
#4 0x7feb3062e655 extensions::AsyncApiFunction::~AsyncApiFunction()
#5 0x7feb307133ef extensions::CastChannelAsyncApiFunction::~CastChannelAsyncApiFunction()
#6 0x7feb30714431 extensions::CastChannelOpenFunction::~CastChannelOpenFunction()
#7 0x7feb30714459 extensions::CastChannelOpenFunction::~CastChannelOpenFunction()
#8 0x7feb3052d81b base::DeleteHelper<>::DoDelete()
#9 0x7feb2f5887ba _ZN4base8internal13FunctorTraitsIPFvPKvEvE6InvokeIJRKS3_EEEvS5_DpOT_
#10 0x7feb2f588738 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvPKvEJRKS5_EEEvOT_DpOT0_
#11 0x7feb2f5886f2 _ZN4base8internal7InvokerINS0_9BindStateIPFvPKvEJS4_EEEFvvEE7RunImplIRKS6_RKSt5tupleIJS4_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#12 0x7feb2f58863c _ZN4base8internal7InvokerINS0_9BindStateIPFvPKvEJS4_EEEFvvEE3RunEPNS0_13BindStateBaseE
#13 0x7feb2f44c441 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv
#14 0x7feb2f44be49 base::debug::TaskAnnotator::RunTask()
#15 0x7feb2f4dea9a base::MessageLoop::RunTask()
#16 0x7feb2f4ded24 base::MessageLoop::DeferOrRunPendingTask()
#17 0x7feb2f4df00e base::MessageLoop::DoWork()
#18 0x7feb2f4f7526 base::MessagePumpGlib::Run()
#19 0x7feb2f4de61a base::MessageLoop::RunHandler()
#20 0x7feb2f5868a4 base::RunLoop::Run()
#21 0x7feb319c503f ChromeBrowserMainParts::MainMessageLoopRun()
#22 0x7feb28cfd9d9 content::BrowserMainLoop::RunMainMessageLoopParts()
#23 0x7feb28d09335 content::BrowserMainRunnerImpl::Run()
#24 0x7feb28cf75a8 content::BrowserMain()
#25 0x7feb2a4421a6 content::RunNamedProcessTypeMain()
#26 0x7feb2a444252 content::ContentMainRunnerImpl::Run()
#27 0x7feb2a441492 content::ContentMain()
#28 0x7feb302bb0cb ChromeMain
#29 0x7feb302bb062 main
#30 0x7feb1c785f45 __libc_start_main
#31 0x7feb302baf65 <unknown>

The problem is that CastChannelOpenFunction is "leaking": it must always respond before it is destroyed. When we call CastSocket::Connect, a callback to respond, which contains a reference to the function, is stored on the CastSocket object.

When extension is unloaded, the CastSocket object is destroyed. At this point, the callback might not have been invoked yet (due to async nature of the operation) but it would simply be destroyed, resulting in a "leak". The fix would be to make sure the callback is invoked when CastSocket is being destroyed.