libminizinc
libminizinc copied to clipboard
MiniZinc does not close generated .fzn before passing it to .msc executable (Windows sharing violation)
This is a problem on Windows, with the minizinc.exe in MiniZincIDE 2.6.4.
It seems that when doing minizinc.exe --solver ".../some.msc" ".../foo.mzn" ".../foo.dzn", where some.msc specified an "executable" some.exe, the some.exe program is passed the path to a generated temporary file with a name like "tmp4711.tmp.fzn" (in some temp directory). So far, so good.
However, it seems that minizinc.exe does not close the generated file before it starts some.exe. This is a problem on Windows, where the default open mode for files is to refuse any kind of sharing. So, a default CreateFile (in some.exe) will fail with ERROR_SHARING_VIOLATION. (This does not happen on POSIX systems, where the default is to silently ignore other writing processes when opening a file for reading, and hope for the best...).
All this is guesswork, based on what my some.exe sees, and what the lockhunter tool says. I looked briefly at the MiniZinc code but could not immediately find the place where the file is created and the some.exe started.
be3dee8 should make the change to ensure that the FlatZinc file is closed before it is given to the solver. It is, however, not something that we can easily write a test case for, so if you could have a look and see if the current develop branch solves the issue for you, then it would be much appreciated.
Do you have prebuilt binaries for the develop branch? Otherwise I would have to build from source, which I have never done, so it would take me some time.
We do build the develop branch using our CI system, but usually not made publicly available. I've temporarily uploaded the Windows version. Let me know if this version works for you.
REMOVED
Thanks, I have downloaded it (so you can stop sharing). I will try to test it next week.
The develop build I downloaded seems to have fixed the bug. Thanks!
Thank you for testing!