Re-occurence of HiGHs failure when called several times in a row
lequant40 opened this issue · comments
Hello !
With version of HiGHs >= 0.4.0, there is a re-occurence of the issue #5 which was fixed in 0.3.0.
This prevents from running HiGHs several times, because it leads to a crash.
This time, though, it seems the error is linked to the input file!
So, after the 4094-th call to HiGHS, the error message is "Error: Unable to read LP model".
Of course, there is no error with the model file itself, but is probably linked - as in the original issue - to an error with the way file descriptors are used either by:
- The HiGHs interface with the new version of emscripten
or - The updated HiGHs version which might have introduced a file handler leak in the C code (ex: not closing the input file after reading it)
I'm attaching a reproducer so that you can include this one in the future unit tests to avoid re-re-occurence of the same problem.
Cheers,
Roman
--
Reproducer, as an HTML file, you just need to open it on a computer with Internet access:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<title>QUnit Example</title>
<link rel="stylesheet" href="https://code.jquery.com/qunit/qunit-2.15.0.css">
<link rel="prefetch" href="https://lovasoa.github.io/highs-js/highs.wasm">
</head>
<body>
<div id="qunit"></div>
<div id="qunit-fixture"></div>
<script src="https://code.jquery.com/qunit/qunit-2.15.0.js"></script>
<script src="https://lovasoa.github.io/highs-js/highs.js"></script>
<script type="text/javascript">
var h;
// ------------------------------------------------------------
QUnit.begin( async details => {
try {
// Load the WASM, which will take some time
console.log("Loading HiGHS Lp solver...");
h = await Module();
console.log("HiGHS Lp solver loaded!");
}
catch (e) {
// Deal with the fact the chain failed
console.error("Error in loading HiGHS Lp solver: " + e);
}
});
QUnit.test('HiGHS loop failure', function(assert) {
// When done
var model = "Minimize \n" + "obj: 6 x0 \n" + "Bounds \n" + "0 <= x0 <= 2 \n" + "End \n";
var cpt = 0;
while (++cpt <= 5000) { // Seems 4094 is KO but 4093 is OK
var sol = h.solve(model);
}
assert.equal(true, true, 'No issues with HiGHs loop');
});
</script>
</body>
</html>
I've verified that the CPLEX-LP file reader in HiGHS closes the file that is passed to Highs::readModel, so I can't see how this bug can be a consequence of HiGHS at this level. I've created the .lp file corresponding to model = "Minimize \n" + "obj: 6 x0 \n" + "Bounds \n" + "0 <= x0 <= 2 \n" + "End \n"; in our TestCAPI.c file. The C API to Highs::readModel is simply a direct call to it, so there's nothing to go wrong here.
Hello @jajhall !
Browsing HiGHS code, it seems ERGO-Code/HiGHS#586 could be related to the current issue.
At least, it would make sense: if HiGHS always tries to create a Highs.log file, this would also create issues with the pseudo file system of emscripten.
I don't have time yet to investigate this issue, but simply updating the version of HiGHS referenced in high-js to the one containing your fix on HiGHS side should allow to confirm/infirm.
Cheers,
Roman
Indeed, updating to (at least) 2acc46c42f1641e1bdb58ab9cf846560bf408bd0 will pick up the changes to the HiGHS logging