[micromega] Revert bad change from 5001deed21e8f4027411cc6413a9d2b98e1bccee

Analysis by Jason Gross:

> The previous semantics was to reset the file offset to 0 during the
> unlock operation, unless it fails, in which case you'd roll back the
> file offset to it's present position (and very dubiously not report
> any issues). The new semantics say to always roll the file offset
> back to it's initial position, meaning that the position is at the
> end of the file after unlocking. As far as I can tell, this results
> in appending marshelled blobs to the cache file on every call to
> add, rather than overwriting the cache file with the marshelled blob
> of the updated table. Presumably unmarshelling the concatenation of
> marshelled data can result in segfaults somehow? This also explains
> why the bug only shows up sometimes; you need to get the system into
> a state where it writes to the cache in a way that concatenates
> blobs in the right way, but once you have such a cache you'll
> segfault every time you read from it.
>
> I think we should probably assert false in the with block, or just
> remove it entirely http://man7.org/linux/man-pages/man3/lockf.3.html
> doesn't say anything about lockf erroring on unlocking). If we start
> seeing errors, we can turn it into a warning.

Closes: #12072

1 files changed, 2 insertions, 2 deletions

diff --git a/plugins/micromega/persistent_cache.ml b/plugins/micromega/persistent_cache.ml
index 9051bbb5ca..3360a9a51c 100644
--- a/plugins/micromega/persistent_cache.ml
+++ b/plugins/micromega/persistent_cache.ml
@@ -93,9 +93,9 @@ module PHashtable (Key : HashedType) : PHashtable with type key = Key.t = struct
            there is a pending lock which could cause a deadlock.
            Should it be an anomaly or produce a warning ?
         *)
-        ()
+        ignore (lseek fd pos SEEK_SET)
     in
-    ignore (lseek fd pos SEEK_SET)
+    ()
 
   (* We make the assumption that an acquired lock can always be released *)