I just had a DCHECK in my local build at
base::debug::BreakDebugger() Line 21
logging::LogMessage::~LogMessage() Line 857
base::ProcessMetrics::ProcessMetrics(void * process) Line 298
base::ProcessMetrics::CreateProcessMetrics(void * process) Line 46
performance_monitor::ProcessMetricsHistory::Initialize(const performance_monitor::ProcessMetricsMetadata & process_data, int initial_update_sequence) Line 53
performance_monitor::PerformanceMonitor::MarkProcessAsAlive(const performance_monitor::ProcessMetricsMetadata & process_data, int current_update_sequence) Line 133
performance_monitor::PerformanceMonitor::MarkProcessesAsAliveOnUIThread(std::unique_ptr<std::vector<performance_monitor::ProcessMetricsMetadata,std::allocator<performance_monitor::ProcessMetricsMetadata> >,std::default_delete<std::vector<performance_monitor::ProcessMetricsMetadata,std::allocator<performance_monitor::ProcessMetricsMetadata> > > > process_data_list, int current_update_sequence) Line 179
On inspection, I see that PerformanceMonitor::UpdateMetricsOnIOThread posts a vector of ProcessMetricsMetadata from IO to UI thread. This contains un-owned process handles, which can't be used except in-context on Windows.
On the UI thread, these handles are then duplicated by the ProcessMetrics, which may lead to all sorts of trouble if the handles have been closed and reused in the meantime (Windows reuses handles aggressively).
I don't know what we use this data for, but this will cause false positive process tracking, false negative process tracking and possibly rare random hangs on Windows.
A reasonable way to deal with this would be something like duplicating the handles at source and to pass them owned by a base::Process instance.
Comment 1 by siggi@chromium.org
, Mar 13 2018