Repository navigation
Can't use proper-lockfile while debugging memory leaks #71
Description
I'm trying to debug memory leaks which involves generating heap dumps. This tends to peg the CPU - when it's done, the process explodes with:
/path/to/node_modules/proper-lockfile/lib/lockfile.js:181
onCompromised: (err) => { throw err; },
^
Error: Unable to update lock within the stale threshold
at options.fs.utimes (/path/to/node_modules/proper-lockfile/lib/lockfile.js:109:21)
at FSReqWrap.oncomplete (fs.js:141:20)
Activity
satazor commentedon Feb 12, 2019
This is the same issue that was reported on ipfs, @hugomrdias will be doing a PR to address the issue.
achingbrain commentedon Feb 19, 2019
How about storing the last modification time after this module updates the lock? That way when
proper-lockfilecomes to updating the lock again, it can compare the current last modification time of the lockfile, and the last modification time when it updated the lock - if they are different then consider the lock stale.This way you don't have to rely on arbitrary timeouts which are too fragile to be used when the thread is suspended (in the case above) or when there is some CPU intensive work going on (in the IPFS case).
satazor commentedon Feb 19, 2019
The solution we discussed a few weeks ago was indeed similar to what you described.
It’s actually pretty easy to implement and to test. I don’t know if @hugomrdias is already on this though.
pimlie commentedon Mar 5, 2019
@satazor Do you maybe have a link to the ipfs issue you are referencing?
We are seeing this same error using proper-lockfile when building a nuxt project on ci's as netlify and wercker
hugomrdias commentedon Mar 5, 2019
im working to fix this problem
feat: make staleness check more robust (#74)