Crash with open files over NFS (+ keep resources busy on NFS)

Pictor13 commented 5 years ago

Description

Since the new 3.2 version of ST I’m noticing many different behaviours concerning the interaction with filesystem (specifically with NFS).

The issues are particularly annoying when working with virtualized environment (our default setup) and none of them was happening with versions < 3.2.

What happens to me (on MacOS 10.14) is:

while in the past I could connect/disconnect volumes without any problem, regardless of SublimeText having any file open on them, now when I try to disconnect a NFS volume, I get an annoying The disk “www” couldn’t be ejected because “Sublime Text” is using it. Now if I can’t temporary quickly switch to another virtualbox; SublimeText forces me to close the project with all its files, and then disconnect the volume; to then allow me to actually re-open SublimeText and open a different project :no_mouth:.
when there are loaded files from a NFS, in SublimeText, if anything happens that disconnects the NFS volume then SublimeText will crash completely and needs to be restarted (but it lost all the undo history, and closed all the open files that didn’t have pending changes to be saved). This is pretty annoying and can happen quite randomly. Actually it happens different times per day because of simply putting my Mac on sleep for a little longer (lunch break, go to the toilet, etc.).
(unrelated to NFS) often I find out that the console doesn’t open anymore using the mouse; one has to use “View”->“Show console”. And also plugins stop working, without any error or report in the console. It simply silently fails calling plugin commands and will start working again just after a restart :man_shrugging:

I just realise now how I loved ST for its unobstructiveness and its stoic endurance without crashing. Since the last release it is soooo sensitive and picky to NFS volumes. And it feels like quite a regression. I am wondering if these are recently introduced bugs or what led to touch the code dealing with the filesystems, and why was that needed (I suppose stuff changed to ease the git integration?)

Looks like now ST needs a constant access to the filesystem and to the opened resources, rather than just load and copy it in memory.

If it is because of git integration I would underline that the GitGutter extension never had such problem (to just say that it is possible to have both git integration and a safe interaction with NFS).

I’d like to know more about it and whether there is active work on that or it is probably gonna stay like this for the future releases.

Steps to reproduce

Steps to reproduce the behavior:

Mount a NFS volume
Load one folder from the volume in ST
Open/edit files and leave them open
Provoke a disconnection of the NFS volume
- shutdown of the remote resource (e.g. suspend virtual machine
- can also happen automatically before the laptop battery is drained
- put the laptop on sleep long enough to provoke a NFS disconnection
Focus the ST application
Look at the crash of the app and meeeh..

Expected behavior & Actual behavior

Previous behaviour was resilient to NFS disconnections and opened files where just transformed automatically to unsaved buffers. With 3.2 the expectation was to preserve this behaviour, not crashing when a network resource is (temporary?) unavailable.

Version info

OS:
Build: 3207

Environment

Build: 3207
Operating system and version: macOS 10.14.3 (18D109)

wbond commented 5 years ago

Do these errors go away if you disable the git integration?

Pictor13 commented 5 years ago

Thanks for the quick reply Will,

Actually yes! It works the old way resilient to whatever is the state of the NFS. Do you think this might be fixable in future releases, still maintaining the git integration?

PS - I didn't have the chance to check for the errors unrelated to NFS yet (console not opening and plugin crashing).

Pictor13 commented 5 years ago

(I also edited the initial post. Sorry for the pain in reading it, I didn't notice it lost the markdown formatting)

wbond commented 5 years ago

So what is likely happening here is that our git library mmaps the various git pack files in order to efficiently read from them. There must be a bug or two related to NFS and the files disappearing, along with how we are reading them.

I would certainly like to think we should be able to find some sort of solution, although I haven't worked too much on our git library. You can see some of what Ben has worked through at https://www.sublimetext.com/blog/articles/use-mmap-with-care.

Pictor13 commented 5 years ago

It's an interesting read; thank you.

According to the article seems like all the issues have been solved for Sublime Merge (at least for 64bit platforms), but is not clear if that's the same also for Sublime Text. I assume that mmap still provokes a kind of lock on the file there, not allowing networked files to disappear or timeout. And it crashes when this happens; or, the other way around, it prevents the unmount on a network volume with opened files (even if they are in idle).

Ideally the same fixes from the article need to be integrated also on Sublime Text? Or, maybe better according to the article's hindsight, just stick to pread as a safer and cleaner approach?

I can survive with git_status: false as long as there's @deathaxe / @jisaacks 's GitGutter active, but from the 3.2 looks like even that one became particularly slow in showing the diff gutters (15 to 30 seconds), without me being able to understand why or how to fix.

Not that I will stop using ST because of this, but I notice that my working flow often happens to be stopped by these annoyances, and for sure I am looking forward to a fixed version that could restore the usual and reliable ST's fluency/performance over NFS.

While a really good work has been done on GitGutter and it was the first & only way to have gutters 'till just recently, I generally would expect the native Git integration to improve and a certain point in the future to replace GitGutter with it.

In general it would be great to have updates on progresses over these issues, approximate estimated times for fixed releases, or suggestions for temporary workarounds.

wbond commented 5 years ago

Sublime Text and Sublime Merge share large portions of their code base, so all Sublime Text releases after the mmap work was done will include them. From looking at the history, these fixes were merged into the codebase in late March, so they should be part of 3207. Based on that, I would say your issue is distinct.

This bug report will be the way to track progress on getting the issue resolved. If you don't see any activity here then there isn't anything to report yet.

Pictor13 commented 5 years ago

Update:

Productivity is back to normal, disabling the git integration (show_git_status: false). And we managed to find what was slowing down gitgutter 👍🏻(https://github.com/jisaacks/GitGutter/issues/546)

But I missed to notice, and to mention, that umounting NFS volumes on Mac is not solved and still gives the problem/warning mentioned above about locked files:

The disk “www” couldn’t be ejected because “Sublime Text” is using it.

My comment wasn't clear enough about that.

dajmon commented 5 years ago

I'm seeing the same behaviour on MacOS 10.14.6 and ST 3211 with AFP mounted volumes that disconnecting/connecting. If you save after remount ST will crash, and sometimes the saved file will be empty which is a critical bug.

com.apple.xpc.launchd[1] (com.sublimetext.3.57864[98187]): Service exited with abnormal code: 1

Will try show_git_status: false.

Tomfox91 commented 3 years ago

FYI, this is still happening in 2021. ST Build 4102, macOS 11.2.3, ST crashes while working on a project mounted through AFP. Will try the workaround of disabling the Git integration.

sublimehq / sublime_text