POSIX shared memory maps lead to semi-permanent disk space leak

[bonachea]

We've noticed that certain usage patterns of POSIX shared memory lead to "permanent" disk space leaks in AppData\Local\lxss\temp. I've searched the Issue Tracker and Google and not found any mention of this particular misbehavior. It's possible this is related to #1940, but we've managed to narrow the misbehavior to a small, reproducible program with no external dependencies that leaks resources on WSL but not native Linux.

• Your Windows build number: (Type ver at a Windows Command Prompt)
  Microsoft Windows [Version 10.0.15063], Linux version 4.4.0-43-Microsoft

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

Here is a simple program that demonstrates the problem. The demo program is a narrowed-down version of code used in the GASNet communication system. The program calls shm_open() to create a shared memory object, does a shm_unlink to remove the system object while maintaining a reference, then ftruncate and mmap to map it into VM, and close on the file handle.

• What's wrong / what should be happening instead:

When you compile and run the above program on WSL with gcc test-pshm.c -lrt && ./a.out, it will leak a 100MB file into the C:\Users\<username>\AppData\Local\lxss\temp\000000000000000c_unlink directory every time you run it (subdirectory might differ based on where you ran the program). These files are not cleaned up after the relevant process exits. They are only cleaned up after every bash process system-wide has exited and WSL is restarted (and seem to cause intermittent errors 0x80070091 and 0x8007005 as WSL cleans up during the next startup of bash). In our "real" applications these shared memory segments are referenced by multiple processes and can be GB in size, but they share the same misbehavior of leaking disk space after all referencing processes have exited. This WSL resource leak very quickly fills a laptop SSD to capacity.

Adding an explicit call to munmap the VM segment before process exit prevents the leak from happening. However this should not be necessary by POSIX semantics, which guarantee that process exit automatically unmaps all memory segments before the process is destroyed. In our real application it's not always possible or safe to insert this munmap (eg during an abortive exit). The same program running on native Ubuntu 14.04.5 (3.13.0-112 kernel) does not leak resources when the munmap is omitted. Same for all the other many flavors of Linux and UNIX we support that include POSIX shared-memory support.

We'd really like a system-level fix to this resource leak to ensure robust behavior. Thanks for your attention to this matter.

Attachments: test-pshm.c

[benhillis]

Thank you very much for the extremely detailed bug report. As you suspected this had to do with us not properly cleaning up some MM state on process exit. I have a fix for this in code review.

[benhillis]

This is fixed in 16278.

[bonachea]

Fix confirmed on build 16278 - Thanks @benhillis !!!!