OPFS leaves AccessHandles open when my app crashes

[rickg-hcl]

Please include the following in your bug report:

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.11-git (1e68a1b)
clang version 21.0.0git (https:/github.com/llvm/llvm-project 2f05451198e2f222ec66cec4892ada0509519290)
Target: wasm32-unknown-emscripten
Thread model: posix

I have spent 2 days trying to create a simple test program the reproduces this, but I could not get it to reproduce.

In our very complicated emscripten application, when it crashes, there are access handles left dangling, such that when we restart, the opens fail with:

Failed to execute 'createSyncAccessHandle' on 'FileSystemFileHandle': Access Handles cannot be created if there is another open Access Handle or Writable stream associated with the same file.

reloading the web page does not resolve the issue, we have close the chrome browser to recover.

I will be creating a pull request that adds a function

void wasmfs_close_opfs_backend(backend_t backend);

That I have tested and solves our problem.

[kripken]

If you build with -sEXIT_RUNTIME, WasmFS should shut down fully as the app exits, and then it might close all handles - but I'm not sure if the backend does that. Worth trying though.

cc @tlively

[tlively]

Since this is a problem caused by exclusive locking, it would also be solved by #21869.

It looks like closing a file does cause the OPFS backend to close the file handle and release the lock, but I don't recall there being any shutdown routine that goes through and manually closes open files. I'm surprised the locks persist through a page reload, but that would be a question for the OPFS spec or implementation, not for Emscripten.

[rickg-hcl]

@tlively That's the point of this issue. We only have a problem when the app crashes, when files are not closed. The PR I created just adds a function that I can call during Module.onAbort to clean up all the open files. It should be harmless for anyone else that doesn't use it.
When we implemented this independently, we proactively closed any file handle that wasn't used for a few seconds to overcome this issue.

[kripken]

If the app crashes, is onAbort guaranteed to be called? I am surprised that is enough. (edit: i mean that a crash can be of the entire tab at the browser level, etc.)

Perhaps there is some OPFS API that we can use at the opposite time, during startup, to get all open file handles and release them?

[kripken]

Though I would hope the browser releases all handles itself when it does a GC.

@rickg-hcl you say restarting the browser is necessary. Is closing the tab and opening another enough? Perhaps with forcing a GC in the devtools? (I'm not suggesting that is a good solution for users, but it would help understand the issue.)

[rickg-hcl]

In our testing closing the tab and reopening it still has the handles open. The browser must be closed to clear it out.

[kripken]

In that case this sounds like a browser bug, and I am surprised we can work around it with onAbort.

Do you see this in other browsers?

[rickg-hcl]

When I tried to run in firefox it didn't work at all. In fact just running the test/wasmfs/wasmfs_opfs.c in firefox hangs after reloading a few times.

emcc -s WASMFS -s PROXY_TO_PTHREAD=1 -s PTHREAD_POOL_SIZE=16 -pthread -o test.html test/wasmfs/wasmfs_opfc.c
emrun --browser=firefox test.html

In my app, reads are very slow in firefox, sometimes never finishing.
I can open a separate issue for that, since it's not really related to the open file handles, I think.

[kripken]

Thanks, I see.

One last thing, does it help if you wait a while rather than restarting Chrome? I ask because perhaps waiting will lead to collection of those objects. If you wait a while and it still errors, then that's probably not the issue.

Regardless of the answer, I think we should file a browser bug on this, unless @tlively you know the right person to cc for OPFS there?

(For the PR, I think it makes sense to hold off until we are sure where the fix should be.)

[tlively]

No, unfortunately my OPFS contact no longer works on OPFS.

[kripken]

Ok, then maybe the best course of action is @rickg-hcl if you can make a small testcase showing the problem, and we'll file a chrome issue with that?

[rickg-hcl]

As I stated in the original description, I spent quite a while trying to create a small testcase that showed the problem, but I was unable to.

[rickg-hcl]

I found a workaround for the firefox issue, and was able to determine that the accessHandles are not left hanging for Firefox, so this seems to be a chrome only problem.

[kripken]

Without a testcase I'm not sure it's worth filing an issue, as it will not be practical for them to investigate. Is your entire app something that you could provide using a URL perhaps @rickg-hcl ?