Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/150777e35b60955ba32a7848f97934efc71dbef2 ([Element Timing] Implement Image Element Timing).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

I keep getting this trace but not just with my change but from way back (I'm trying to bisect):

../../base/metrics/persistent_memory_allocator.cc:353:3: runtime error: member access within null pointer of type 'base::PersistentMemoryAllocator::SharedMetadata'

DevTools listening on ws://127.0.0.1:34589/devtools/browser/87915af7-2063-4a06-b880-52b380b01c98
    #0 0xf5e6495 in base::PersistentMemoryAllocator::PersistentMemoryAllocator(base::PersistentMemoryAllocator::Memory, unsigned long, unsigned long, unsigned long, base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, bool) base/metrics/persistent_memory_allocator.cc:353:3
    #1 0xf5ed601 in base::SharedPersistentMemoryAllocator::SharedPersistentMemoryAllocator(std::__1::unique_ptr<base::SharedMemory, std::__1::default_delete<base::SharedMemory> >, unsigned long, base::BasicStringPiece<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, bool) base/metrics/persistent_memory_allocator.cc:1024:7
    #2 0xf5a1137 in base::FieldTrialList::InstantiateFieldTrialAllocatorIfNeeded() base/metrics/field_trial.cc:1397:11
    #3 0xf5a1cf1 in base::FieldTrialList::CopyFieldTrialStateToFlags(char const*, char const*, char const*, base::CommandLine*) base/metrics/field_trial.cc:929:5
    #4 0xd27480d in content::GpuProcessHost::LaunchGpuProcess() content/browser/gpu/gpu_process_host.cc:1046:3
    #5 0xd26ec82 in content::GpuProcessHost::Init() content/browser/gpu/gpu_process_host.cc:814:15
    #6 0xd26df08 in content::GpuProcessHost::Get(content::GpuProcessHost::GpuProcessKind, bool) content/browser/gpu/gpu_process_host.cc:542:13
    #7 0xd230b33 in content::BrowserGpuChannelHostFactory::EstablishRequest::EstablishOnIO() content/browser/gpu/browser_gpu_channel_host_factory.cc:135:26
    #8 0x6cf4bf9 in base::OnceCallback<void ()>::Run() && base/callback.h:99:12
    #9 0xf5850c6 in base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) base/debug/task_annotator.cc:101:33
    #10 0xf57dd78 in base::MessageLoop::RunTask(base::PendingTask*) base/message_loop/message_loop.cc:434:46
    #11 0xf57e9a4 in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) base/message_loop/message_loop.cc:445:5
    #12 0xf57f72f in base::MessageLoop::DoWork() base/message_loop/message_loop.cc:517:16
    #13 0xf8e119b in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) base/message_loop/message_pump_libevent.cc:210:31
    #14 0xf62f482 in base::RunLoop::Run() base/run_loop.cc:102:14
    #15 0xc76eafb in content::BrowserProcessSubThread::IOThreadRun(base::RunLoop*) content/browser/browser_process_sub_thread.cc:175:11
    #16 0xf793b98 in base::Thread::ThreadMain() base/threading/thread.cc:357:3
    #17 0xf8c3de1 in base::(anonymous namespace)::ThreadFunc(void*) base/threading/platform_thread_posix.cc:76:13
    #18 0x7f123fde1493 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x7493)
    #19 0x7f123a164a8e in clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8a8e)

Adding PerfAPIs component in case this is actually caused by my CL.

It looks like the above stacktrace is from old code and not related to this particular bug. I was able to reproduce the stacktrace from this bug via "clusterfuzz reproduce".

The crash is caused by the 'existence' of the "timing/performance_element_timing.idl" in core_idl_files.gni. I say existence because if I comment the lines in WindowPerformance::AddElementTiming (only user of PerformanceElementTiming) then:
1. Removing "timing/performance_element_timing.idl," from core_idl_files.gni causes no stacktrace to be produced.
2. Readding the text to core_idl_files.gni (without uncommenting the lines from WindowPerformance::AddElementTiming) causes the stacktrace to show up.

This is qute bizarre to me: why would just adding the idl file trigger this crash? +kbr@ you added gl::Crash. Any thoughts on what could be going on here?

I've been receiving bugs from Clusterfuzz about the gl::Crash entry point I added and it looks to me like it's fuzzing interfaces (the gpu_benchmarking_extension which is enabled for testing only via command line flag) which it shouldn't be. I've asked repeatedly for Clusterfuzz to stop fuzzing that entry point but so far no reply from the CF team.

ClusterFuzz testcase 4579609109331968 appears to be flaky, updating reproducibility label.

I think inferno@ already added a suppression for gl::Crash under another bug.