Øyvind Harboe

Unsure how to proceed with debugging, because it crashes only in the bazel-orfs context. What is stranger is that bazel doesn't stop upon signal 6 from the underlying process, bazel...

This is a successful run from docker image [v3.0-2863-g22e02291](https://hub.docker.com/layers/openroad/orfs/v3.0-2863-g22e02291/images/sha256-c55f54b42bda21749b3d0b14e35d0c2be2ec57e6fcfe7063932faa417ffd9ce5) It took ca. 45 minutes. Of course, the input to CTS will be different. I think it is worth having a...

@maliberty Could it be that there are hopeless hold violations that make the test case take forever and ultimately crash (in some cases)?

> I wouldn't expect a crash unless you are running out of memory. futile hold repair running out of memory?

> Possibly but hard to say without know the job size, machine size, available swap, etc. It would be nice if hold repair gave up quickly on lost causes. I...

`perf top` from repairing 1 endpoint. ``` repair_timing -verbose -setup_margin -1300 -hold_margin -200 -repair_tns 0 [INFO RSZ-0094] Found 24253 endpoints with setup violations. [INFO RSZ-0099] Repairing 1 out of 24253...

@maliberty @precisionmoon Is this a smoking gun? It shouldn't take more than minutes to fix a single end-point, right?

If there is a text we can use here for deltaDebug, then we can whittle it down. Perhaps it should never take more than, say 100, iterations to repair a...

So if we're repairing a single endpoint and the worst endpoint changes, then we've made the worst endpoint better than the second worst. Could that be a natural time to...

@precisionmoon Could this just be an interesting edge case that is triggered by some unfortunate initial conditions? I'm bumping ORFS on MegaBoom to see if upgrading makes the problem magically...