We are suspecting a memory leak related to this hash table:

https://cs.chromium.org/chromium/src/content/browser/streams/stream_registry.h?l=68&rcl=1bafcfdfcc6867b9be120e54c73b0ea526cd886e

The potential leak is happening when allocated here:
https://cs.chromium.org/chromium/src/content/browser/fileapi/fileapi_message_filter.cc

I took a trace after starting the web browser (with memory dump, --enable-heap-profiling=native). Then, I did a few default page reload (about 200). I took a snapshot again. And, I did the same steps a few time. I looked to the allocated objects with a common stack frame that are increasing.

Here is the culprit stack frame:
  u'operator new\r',
      u'std::_Allocate\r',
      u'std::basic_string<char,std::char_traits<char>,std::allocator<char> >::_Copy\r',
      u'std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign\r',
      u'std::_List_buy<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Buynode<std::basic_string<char,std::char_traits<char>,std::allocator<char> > & __ptr64>\r',
      u'std::_Hash<std::_Uset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::_Uhash_compare<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::hash<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::equal_to<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,0> >::_Buynode_if_nil<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const & __ptr64>\r',
      u'std::_Hash<std::_Uset_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::_Uhash_compare<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,base_hash::hash<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::equal_to<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,0> >::_Insert<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const & __ptr64,std::_Nil>\r',
      u'content::FileAPIMessageFilter::OnStartBuildingStream\r',
      u'IPC::MessageT<StreamHostMsg_StartBuilding_Meta,std::tuple<GURL,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,void>::Dispatch<content::FileAPIMessageFilter,content::FileAPIMessageFilter,void,void (__cdecl content::FileAPIMessageFilter::*)(GURL const & __ptr64,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const & __ptr64) __ptr64>\r',
      u'content::FileAPIMessageFilter::OnMessageReceived\r',
      u'content::BrowserMessageFilter::Internal::OnMessageReceived\r',
      u"IPC::`anonymous namespace'::TryFiltersImpl\r",
      u'IPC::MessageFilterRouter::TryFilters\r',
      u'IPC::ChannelProxy::Context::TryFilters\r',
      u'IPC::ChannelProxy::Context::OnMessageReceived\r',
      u'IPC::ChannelMojo::OnMessageReceived\r',
      u'IPC::internal::MessagePipeReader::Receive\r',
      u'IPC::mojom::ChannelStubDispatch::Accept\r',
      u'mojo::InterfaceEndpointClient::HandleValidatedMessage\r',
      u'mojo::FilterChain::Accept\r',
      u"IPC::`anonymous namespace'::ChannelAssociatedGroupController::Accept\r",
      u'mojo::FilterChain::Accept\r',
      u'mojo::Connector::ReadSingleMessage\r',
      u'mojo::Connector::ReadAllAvailableMessages\r',
      u'mojo::SimpleWatcher::OnHandleReady\r',
      u'base::internal::InvokeHelper<1,void>::MakeItSo<void (__cdecl syncer::ModelTypeConnector::*const & __ptr64)(enum syncer::ModelType,enum syncer::ModelSafeGroup) __ptr64,base::WeakPtr<syncer::ModelTypeConnector> const & __ptr64,enum syncer::ModelType const & __ptr64,enum syncer::ModelSafeGroup const & __ptr64>\r',
      u'base::debug::TaskAnnotator::RunTask\r',
      u'base::MessageLoop::RunTask\r',
      u'base::MessageLoop::DoWork\r',
      u'base::MessagePumpForIO::DoRunLoop\r',
      u'base::MessagePumpWin::Run\r',
      u'base::RunLoop::Run\r',
      u'content::BrowserThreadImpl::IOThreadRun\r',
      u'content::BrowserThreadImpl::Run\r',
      u'base::Thread::ThreadMain\r',
      u"base::`anonymous namespace'::ThreadFunc\r",
      u'BaseThreadInitThunk\r',
      u'RtlUserThreadStart\r',
      u'[Thread: Chrome_IOThread]']


In the first two iterations, the leaking stackframe was not present (below 1000 objects allocated). Then it shows up and keep increasing:

4386 -> 8364