Handle MT issues in setVertexArrivals, fix non-determ crash

[dsengupta0628]

Issue 1
Rapidus hercules_idecode hits non-deterministic STA assertion · Issue #1537 · The-OpenROAD-Project-private/OpenROAD-flow-scripts
Non-deterministic segmentation fault in GRT

sta::Path::vertexPath
sta::ArrivalVisitor::pruneCrprArrivals
sta::ArrivalVisitor::visit
sta::DispatchQueue::dispatch_thread_handler

Issue 2
Rapidus hercules_is_int with M4D1 parasitics hits STA assertion · Issue #1526 · The-OpenROAD-Project-private/OpenROAD-flow-scripts
Non-deterministic STA assert in CTS (most-shallow stack same as above)

sta::CheckCrpr::findCrpr
sta::Latches::latchBorrowInfo
sta::Latches::latchRequired
sta::Latches::latchOutArrival
sta::PathVisitor::visitFromPath
sta::PathVisitor::visitEdge
sta::PathVisitor::visitFaninPaths
sta::ArrivalVisitor::visit

Both happen because setVertexArrivals() unconditionally mutates vertex->paths_ with no protection, while the multi-threaded BFS allows other threads to simultaneously read another vertex's path array through the CRPR clock path lookup (crprClkPath() → Path::vertexPath()). The two crashes represent the same data race manifesting at different points in the call:

Crash in Issue 1 fails immediately in vertexPath,
Crash in Issue 2 uses a transiently valid pointer that becomes dangling before findCrpr dereferences it, producing garbage that overflows the genclk_src_paths_ vector index.

To fix this, we defer deletion of old vertex path arrays until after visitParallel completes.
So in setVertexArrivals, instead of immediately deleting the old path array (which frees memory that concurrent CRPR/latch readers may still hold pointers to), save it to a per-search list and free it in deleteTagsPrev() — which is called only after all threads for a level have finished.

Why this fixes both crashes ?

Issue 1 (Path::vertexPath ← pruneCrprArrivals):
Thread B was freeing Vclk->paths_ via deletePaths()/makePaths() while Thread A read Vclk->paths_[path_index]. The old array is now kept alive until deleteTagsPrev(), so Thread A's pointer is always
valid within the parallel level.

Issue 2 ('_n < size()' ← findCrpr ← latchBorrowInfo):
Thread A obtained a const Path *src_clk_path via crprClkPath() pointing into Vclk->paths_. Thread B freed that array. Dereferencing the dangling pointer produced garbage rf/min_max indices, which overflowed the genclk_src_paths_ vector. With deferred deletion the returned pointer stays valid, so findCrpr reads correct data.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
5 out of 6 committers have signed the CLA.

✅ maliberty
✅ dsengupta0628
✅ povik
✅ vvbandeira
✅ hzeller
❌ fredowski
_{You have signed the CLA already but the status is still pending? Let us recheck it.}