[GeneralDichotomy] allow any primal feasible point from subsolve

[odow]

x-ref #209 (comment)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.74%. Comparing base (5cfef38) to head (23de12f).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #210      +/-   ##
==========================================
- Coverage   99.64%   97.74%   -1.91%     
==========================================
  Files          15       14       -1     
  Lines        1424     1374      -50     
==========================================
- Hits         1419     1343      -76     
- Misses          5       31      +26     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[odow]

@filikat and @Opt-Mucca, here's another stack trace:

[Opt-Mucca]

@odow If I had to guess:

Can you re-run the test with these lines removed from HighsMipSolver::cleanupSolve()?

for (HighsMipWorker& worker : mipdata_->workers) {
    assert(worker.solutions_.empty());
  }

I put that there mainly for debugging (to protect against the case that we weren't flushing workers via some solution path), but I'm now worried that it raises an error if you re-solve using the same HiGHS model and the instance is solved by presolve.

Edit: I can just make the PR.....

[filikat]

for (HighsMipWorker& worker : mipdata_->workers) {
    assert(worker.solutions_.empty());
  }

This loop does nothing in release @Opt-Mucca.
The stack trace shows the segfault in HighsProfiling::stop.
It doesn't seem related to the parallel scheduler anyway.

[Opt-Mucca]

@filikat I have no clue how I missed the line above with HighsProfiling...... This is probably to do with the change to the timers then?
I do think the lines I've removed may still actually be a bug for some fringe re-solve solution paths

[filikat]

I have no clue how I missed the line above with HighsProfiling

@Opt-Mucca Cpp name mangling is not exactly easy to read...

I do think the lines I've removed may still actually be a bug for some fringe re-solve solution paths

Totally possible, but this bug would only appear when compiling in debug, since the asserts do nothing in release and the whole loop gets removed by the compiler.

[odow]

We can’t easily test changes to HiGHS in these tests. Even debug mode isn’t really possible