mpl: rtl_macro_placer segfaults when invoked a second time in the same process

Describe the bug

Calling rtl_macro_placer a second time in the same OpenROAD process segfaults (Signal 11). HierRTLMP::run() ends by calling clear(), which destroys the physical hierarchy tree; the tree is only ever created in the constructor, so the second invocation hands a null tree to the clustering engine.

Any workflow that generates several macro placements in one process (candidate sweeps, in-process retries) hits this immediately.

To reproduce

From src/mpl/test (uses only in-repo test files):

read_lef Nangate45/Nangate45.lef
read_lef testcases/orientation_improve1.lef
read_def testcases/halos1.def
set_thread_count 0
rtl_macro_placer -report_directory rtlmp_run1
puts "first run done"
rtl_macro_placer -report_directory rtlmp_run2
puts "second run done"

Observed: first run done, then Signal 11 received with a stack trace. Expected: the second run either works (treating the now-LOCKED macros as an all-fixed design) or fails with a diagnostic — anything but a crash.

Environment

OpenROAD master 3ca581e384324a1d09a53d29b00d4fad1c365e70, Linux x86_64, bazel build.

We currently carry a fix downstream (recreate the tree in init() and reset the stale skip_macro_placement_ flag) as a patch in bazel-orfs and can upstream it once the ongoing mpl churn settles.

🤖 Generated with Claude Code