From daa5d0f71657d49965f1334e417f6e0f2e13e8d9 Mon Sep 17 00:00:00 2001 From: Emilio Jesus Gallego Arias Date: Thu, 14 May 2020 02:56:26 +0200 Subject: [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 --- plugins/micromega/persistent_cache.ml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'plugins/micromega/persistent_cache.ml') 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 *) -- cgit v1.2.3