CRITICAL DEADLY BUG: WSL2/VSCODE/Docker Desktop Memory Leak clobbers WSL /home/username/* ALL files Suddenly Disappear!

Windows Version

Microsoft Windows [Version 10.0.19045.2604]

WSL Version

1.0.3.0

Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version

5.15.79.1

Distro Version

Ubuntu-20.04

Other Software

Docker Desktop 4.17.0 (99724) is currently the newest version available. With the previous version having MONSTER BUGS!

Visual Studio Code - Insiders ( all details ): Version: 1.76.0-insider (user setup) Commit: 92da9481c0904c6adfe372c12da3b7748d74bdcb Date: 2023-02-28T11:50:30.886Z Electron: 19.1.11 Chromium: 102.0.5005.196 Node.js: 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0.19045 Sandboxed: Yes

Repro Steps

When using WSL2 from the Terminal inside VSCODE output became corrupt when using commands then the entire /home/username/* files gone THE PAIN IS HOWLING! The directory /home/username remained with NOTHING in there. VSCODE editor shows files tabs names crossed out (files had vanished but not the editor buffer) - so able to save (to /mnt/c/Users/username/someplace) only those files that were still in the VSCODE editor buffers. Some VSCODE - insiders editor buffers were needing refreshing so could not read VANISHED files.

Fully integrated with Docker Desktop. Image show settings. Appears to be a WSL2 memory corruption. With perhaps integration issues with Docker Desktop. DockerDesktop

Expected Behavior

Expect WSL2, Docker Desktop, Output from echo $USER or echo $HOME is NOT garbled. Expect WSL2 TO ABSOLUTLY GUARD /home/usrerame/* files and directories and NOT **** VANISH PEOPLES WORK IN AN INSTANT! FINALLY: Expect the year old bug reporting THE SAME SYMPTOMS NOT to be closed. Swear words removed!! !! SOMEBODY Closed this similar issue: https://github.com/microsoft/WSL/issues/4974

(and note well ALL, every item of software being used has been updated since that issue was closed 3 years ago.)

Actual Behavior

Command output on the command line garbled for example this suggests that WSL bash memory has been corrupted but NOT env memory. The env command has ZERO corrupt output. The echo command outputs garbage. Two examples. This is associated with ALL files gone.
58:/home$ echo $USER clu e~#5df oqYx 58:/home$ echo hay diddle diddle the cat and the fiddle $HOME hay diddle diddle the cat and the fiddle /home/ clu e

Example where $USER and $HOME cant be used. The fragility of WSL VSCODE and Docker Desktop does mean I have backups. Done as follows (this example AFTER the event): -First save back the contents of VSCODE open file buffers (that report vanished files in VSCODE). Then ...

cd ~/.. # Do the next command but DO NOT USE the shell variables, replace them BY HAND.
Replacing BY HAND the $USER in the command below works. ONLY MANAGED TO RECOVER 3 FILES everything else even .bashrc gone.
sudo tar --numeric-owner --one-file-system -p -cJf /mnt/c/Users/$USER/wslbackup${USER}9.tar.xz ./$USER

NOTICE THE CORRUPTIONS ABOVE BUT other observations hint at developers (WSL2/VSCODE - insiders and Docker Desktop) brain-dead ignoring memory leaks! 1) Additional HINTS that some memory corruption is VSCODE and WSL Terminal related: Switching between applications causes VSCODE and OR WSL to lose focus on whatever it was LAST focused on ANOYING!

2) Additional HINT that VSCODE is "Annoyingly prompting" users NOT to past text into the terminal to avoid corruption. Suggests this ANOYING feature was prompted by developers "THINKING" that users were pasting rm -rf by mistake when they WERE NOT. Hence this image attached below. THEY WERE BLAMING THE USERS!!!!!!!!! WRONGLY!!!! MemoryLeak

3) Additional HINT that developers are THINKING THEY FIXED IT BUT HAVE NOT is the following bug report. https://github.com/microsoft/WSL/issues/4974 and the symptoms look similar: Vanishing all your WSL user home area files and the PAIN of the users is clear!

4) Previous bugs associated with Docker Desktop to WSL face-plant integration show /usr/bin/docker file path SUDDENLY VANISHES. But the link to the file EXISTS in Windows!!!!!!! Comes back with a reboot. Anoying!

5) WSL2 Network connectivity does not always come up. Possibly related WSL connection to the Network VANISHES the DNS settings so the ONLY way to get it back is with REBOOTING, usually 2 times does the trick. WSL2 LOSING NETWORK DNS CONNECTIVITY COULD BE THE SAME MEMORY CORRUPTION clobbering WSL2 internal metadata for the DNS. All NON-WSL network connections stay working eg this bug report getting created.

6) HINT something VERY BAD going on is a BASH CRASH. Starting a WSL2 Terminal in VSCODE and start typing something at the command prompt ... bash suddenly disappears and comes back instantly so that you have to start typing the command again!!!! Sounds like a crash that WSL detected but then a "mutt hack code" detects the bash crash and simply restarted BASH. THAT IS SUPER UGLY! Happens 1 in 3 times WSL Terminal first opens in VSCODE - insiders.

7) This bug may be Docker Desktop related memory corruptions as previous symptoms causes WSL integration settings with Docker Desktop to VANISH. Equally it could be VSCODE - insiders or WSL. BUT THE BOTTOM LINE is WSL FAILS TO GUARD AND PROTECT /home/username/* and all directories. THEY CONTINUE TO JUST VANISH! This is the SIMILAR problem as a 3 year old bug report: SOMEBODY Closed this similar issue: https://github.com/microsoft/WSL/issues/4974

8) Something bad is going on when Microsoft tries to do Linux and implements it in WSL totally in an insecure way. WSL is implemented LIKE A DOCKER CONTAINER, which is insecure obviously, but then implemented like a pretend Linux app but the app is Windows so by definition it can't be secure. Linux under Windows is an oxymoron. (not a swear word)

Diagnostic Logs

Not permitted too private.

THE RELATED ISSUE CLEARLY IS NOT FIXED: https://github.com/microsoft/WSL/issues/4974 Important suggestions:
1) WSL2 developers need to place MEMORY TOP guard markers in different places eg heap and stack, and monitor it for being overwritten. 2) Also please use memory leak code quality analysis tools as C++ users do. Use both static and dynamic analysis tools for code quality. 3) Test for memory corruption and leaks, uninitialized pointers, pointers being REused after freeing memory etc 4) Test for buffer overflows, and memory scribblers that "clobber next door code and memory". 5) Avoid rogue memory management systems that clean-up too early eg Microsoft .NET Jit. You will get the Jitters!!! Just thoughts.

I can sense your frustration, but if I could offer some feedback on your report:

Hyperbolic language and all caps will not improve the response time from the WSL team
Batching other various complaints/bugs about WSL and/or Docker Desktop is confusing, may be cathartic, but does not allow the issue to be isolated and addressed
Providing more details steps to reproduce: When using WSL2 from the Terminal inside VSCODE output became corrupt when using commands Which commands?
Can you be more specific about why you think a memory corruption issue led to file deletion? I am not clear on the connection.
Editorializing with Something bad is going on... is not helpful, nor is an Issue the proper place to discuss these issues.

Google Reports 90 000 HITS on "disappearing or vanishing files 5 Year old Microsoft WSL1 and WSL2 bug, lost all user files!"

The new environment that VSCODE provides with an interface into WSL2 and Docker containers at the same time is nothing short of outstanding! Sadly a catastrophic hyperbolic bugs remain in WSL2, Docker Desktop and VSCODE. I report a new part of this bug which I have just noticed, it is related to one many years old New related in my case /etc/wsl.conf has gone too not just ALL FILES under $HOME Capitals for good a reason. Users please backup.

What I did to backup fortunately. Lucky also VSCODE editor buffers stayed open (when all of $HOME had gone).
The open files (buffers only) in VSCODE enabled files to be "Saved as" into: /mnt/c/Users/username/filename Please backup whilst WSL2/VSCODE or Docker Desktop is unstable:-

1) 
  cd ~/..  # From /home in wsl not $HOME   # In a WSL Terminal
  sudo tar --numeric-owner --one-file-system -p -cJf  /mnt/c/Users/$USER/someDir/wsl_backup_${USER}3.tar.xz   ./$USER

2)  Also copy your /etc/wsl.*  and /etc/resolv.*  to someplace safe.

Version of WSL (beyond the parts already internal to Windows 10/11) are the latest blob (not installed from Windows app store).
https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi MD5 and SHA256 of this file is:

$ md5sum wsl_update_x64.msi
655e917f1182d65ae42a70eadaed8b88 *wsl_update_x64.msi

$ sha256sum wsl_update_x64.msi
4d09c776c8d45f70a202281d18e19be1118f53159b0c217a5274a31ce18525fe *wsl_update_x64.msi

REF Previous posted comment accusing me of not including commands. The commands are clearly in the text; full output of the commands are also included with the very first post, (but not marked as code - sorry). There are no prior steps except running make files for builds that call compilers (BUILDS DELETED history DELETED BY YOUR BUG - UNDERSTAND THAT!). I will try to capture specific causes but that is almost impossible because it DELETES EVERYTHING in $HOME.

Relevant setting missing from my bug report $HOME/.wslconfig contained this on a 16GB Dell laptop (not reported because $HOME was destroyed with all files including history, I repeat including history):

settings/wsl_user$ cat ~/.wslconfig # Fortunately users that backup get to post DELETED FILES in bug reports!

[wsl2]
memory=6GB      # Limits VM memory in WSL 2
processors=2    # Makes the WSL 2 VM use n virtual processors
[boot]
systemd=true
command = service docker start

When reporting the most serious bugs, it is harder when the bug itself deletes ALL EVIDENCE of the sequence of commands that triggers that bug in the first place, a bug 5 years old!

It is understandable how serious this bug is in both this report and related issues 5 years ago, 3 years ago and now, causing all work to be lost. This naturally causes people to go hyperbolic! Normally bugs are annoying, this is 100x worse than annoying, and somebody who worked at Bell Labs when Kernighan, Richie, Pike and Thompson when they worked there is posting this. Dennis Richie died only days after Steve Jobs. If you wish to insult people who spend time reporting the bug who know UNIX and Linux VERY well, it is a bad move for a kid! The previous time this happened 3 years ago people were hyperbolic THE PATTERN WAS THE SAME $HOME files all gone. Sorry about the caps in $HOME.

`That means ... if the bug with the same symptoms of deleting all user home files appears 5 years ago, 3 years ago and now, you probably know what causes it, somebody in your team has seen it before! It is a catastrophic bug, not a simple annoying one!

People CLOSED those previous bugs for a reason, or did not bother to fix them? `

It is interesting that /etc/wsl.conf also has gone. In the weeks prior to this 2/3 of the time WSL connectivity to the network fails on reboot. You reboot on average 3 times to get it back. Since the noise on the internet related to WSL2 and Docker Desktop instability being very loud users are backing up, those that get this bug will be allowed to be HYPERBOLLIC!

Thank you for reporting the issue, I'd like to look into it, but I'm having a very difficult time trying to parse this issue. In order to make this actionable, can you please summarize the issue into three succinct parts? I can understand you're frustrated, but please try to provide a brief description of:

Repro steps
Observed behavior
Expected behavior

New data "BREAKING BAD" log. This (same/related) bug happens when copying large numbers of files from one directory to another under a WSL terminal inside VS CODE. It also happens without VSCODE with Windows System for Linux vanilla Penguin icon Terminal. The directory copied was a git project also volume mounted to a single docker image. WSL like early days Windows itself had no security designed in from the get-go; then it had to be "patched" on top and patched on top of parches a thousand times so the patches tear apart. WSL is the same, the lack of security is glaring to say the least and this is down to the WSL being oblivious to the core of Linux where every IO goes via files and all files are via the kernel and all files have user/group access permissions therefor all IO has access permissions. You then broke Linux, because "all IO has broken Windows ideas" for file use that BREAKS LINUX. So WSL is broken to the design core, naturally WSL is an oxymoron of Linux under Windows for that exact "file" reason. The first mistake you made was you chose the worst Linux to hijack inside Windows - Alpine Linux and I only realised this from the log below!
This crash is repeatable with errors in the log below, and also kills and corrupts the open FILENAMES of MS Word so the file names all become "Install VS Code", Teams also stops working with loss of Ethernet. At the same time Docker Desktop freezes solid. Not only are previous bugs deleting everything under /home/bellsec0/* user home area this related one also clobbers work in progress in open MS Word and cuts Ethernet. The last time bugs like this happened was when VSCODE upgrades without asking you (WITHOUT ASKING)!
So using the words CRITICAL DEADLY BUG is not hype, and since this is "Linux", I am not a Microsoft fan for many good reasons. The only reason you would use Docker and Linux near Microsoft is because larger corporations have MS server addictions backed by IT, the good news is final code I build runs directly on Linux target hardware without MS or Docker.

Notice that BREAKING BAD pattern: I needed to speed VS up and have privacy because it is a MEDICAL PROJECT, so when turning VS CODE and Visual Studio telemetry OFF, the exact same logs that VS telemetry uses continue to grow and are accessed by other Windows services (so no speedup). So the VS definition of "telemetry OFF" is BREAKING BAD like the TV series. Windows has no security designed in from the get-go, Linux does. Bugs in the code can't be fixed because the true bugs are in the design itself and in philosophy of the staff. The idea that Windows OS must upgrade or VS or WSL must upgrade without asking is deadly as proven by Microsoft devices in hospitals rebooting with a patch (with an upgrade warning box that counts down). Loss of trust in Microsoft is justified by having telemetry on by default and FAKE off when set to off. That means "by default and on purpose" violating privacy laws in at least 20 countries. All Bell Labs engineers agree with me: Linux on top of Windows ~~~~s and Docker is strictly only for dev and test not for release, Docker is as insecure as Windows and both are agency compromised violating privacy as this log hints at.

WSL CRASH LOG ON THE VSCODE WSL TERMINAL [2023-03-21 16:04:01.913] Resolving wsl+ubuntu-20.04, resolveAttempt: 1 [2023-03-21 16:04:02.378] Starting VS Code Server inside WSL (wsl2) [2023-03-21 16:04:02.378] Extension version: 0.76.1 [2023-03-21 16:04:02.378] Windows build: 19045. Multi distro support: available. WSL path support: enabled [2023-03-21 16:04:02.378] No shell environment set or found for current distro. [2023-03-21 16:04:04.530] WSL daemon log file: [2023-03-21 16:04:04.531] Probing if server is already installed: C:\Windows\System32\wsl.exe -d Ubuntu-20.04 -e sh -c "if [ -d ~/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884 ]; then printf 'install-found '; fi; if [ -f /etc/alpine-release ]; then printf alpine-; fi; uname -m" [2023-03-21 16:04:05.658] Probing result: install-found x86_64 [2023-03-21 16:04:05.658] Server install found in WSL [2023-03-21 16:04:05.659] Launching C:\Windows\System32\wsl.exe -d Ubuntu-20.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" ee2b180d582a7f601fa6ecfdad8d9fd269ab1884 stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=1624770396-596768363-4019329310-2581202185 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all' [2023-03-21 16:04:06.364] Setting up server environment: Looking for /home/bellsec0/.vscode-server/server-env-setup. Not found. [2023-03-21 16:04:06.365] WSL version: 5.15.90.1-microsoft-standard-WSL2 Ubuntu-20.04 [2023-03-21 16:04:06.365] WSL-shell-PID: 152 [2023-03-21 16:04:06.365] Node executable: /home/bellsec0/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884/node [2023-03-21 16:04:06.365] Starting server: /home/bellsec0/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884/bin/code-server --host=127.0.0.1 --port=0 --connection-token=1624770396-596768363-4019329310-2581202185 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all [2023-03-21 16:04:06.365] [2023-03-21 16:04:06.365] Visual Studio Code Server [2023-03-21 16:04:06.365] [2023-03-21 16:04:06.365] By using the software, you agree to [2023-03-21 16:04:06.365] the Visual Studio Code Server License Terms (https://aka.ms/vscode-server-license) and [2023-03-21 16:04:06.365] the Microsoft Privacy Statement (https://privacy.microsoft.com/en-US/privacystatement). [2023-03-21 16:04:06.365] * [2023-03-21 16:04:06.365] Server bound to 127.0.0.1:43125 (IPv4) [2023-03-21 16:04:06.365] Extension host agent listening on 43125 [2023-03-21 16:04:06.365] [2023-03-21 16:04:06.378] Started local proxy server on 49906. [2023-03-21 16:04:06.378] WSL resolver response: 127.0.0.1:49906 [2023-03-21 16:04:06.378] To debug connection issues, open a local browser on http://127.0.0.1:49906/version [2023-03-21 16:04:06.378] Using 'wslExeProxy' to connect to the VS Code server as configured by setting 'remote.WSL2.connectionMethod' [2023-03-21 16:04:06.378] 'wslExeProxy' should fix reconnection issues after sleep and network adapter changes. [2023-03-21 16:04:06.378] Please report issues related with the new setting to https://github.com/microsoft/vscode-remote-release/issues/5894 [2023-03-21 16:04:06.379] To revert back to the old way of connecting, change setting 'remote.WSL2.connectionMethod' to 'wsl2VMAddress'. [2023-03-21 16:04:07.495] Download in background is enabled [2023-03-21 16:28:07.982] Update check by another window detected, skipping. [2023-03-21 17:25:39.088] Update check by another window detected, skipping. [2023-03-21 17:30:16.247] [16:04:06] [2023-03-21 17:30:16.247] [2023-03-21 17:30:16.247] [2023-03-21 17:30:16.247] [2023-03-21 17:30:16.247] [2023-03-21 17:30:16.247] [16:04:06] Extension host agent started. [2023-03-21 17:30:16.247] [16:04:06] [127.0.0.1][1c7bd563][ManagementConnection] New connection established. [2023-03-21 17:30:16.247] [16:04:08] [127.0.0.1][deff4122][ExtensionHostConnection] New connection established. [2023-03-21 17:30:16.247] [16:04:08] [127.0.0.1][deff4122][ExtensionHostConnection] <233> Launched Extension Host Process. [2023-03-21 17:30:16.248] [16:04:34] [File Watcher (node.js)] Watcher shutdown because watched path got deleted [2023-03-21 17:30:16.249] VS Code Server for WSL closed unexpectedly. [2023-03-21 17:30:16.250] C:\Windows\System32\wsl.exe -d Ubuntu-20.04 -e kill 152 [2023-03-21 17:30:16.259] Resolving wsl+ubuntu-20.04, resolveAttempt: 2 [2023-03-21 17:30:16.684] Starting VS Code Server inside WSL (wsl2) [2023-03-21 17:30:16.684] Extension version: 0.76.1 [2023-03-21 17:30:16.684] Windows build: 19045. Multi distro support: available. WSL path support: enabled [2023-03-21 17:30:16.684] No shell environment set or found for current distro. [2023-03-21 17:30:18.735] WSL Daemon exited with code 0 [2023-03-21 17:30:18.859] WSL daemon log file: [2023-03-21 17:30:18.861] Probing if server is already installed: C:\Windows\System32\wsl.exe -d Ubuntu-20.04 -e sh -c "if [ -d ~/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884 ]; then printf 'install-found '; fi; if [ -f /etc/alpine-release ]; then printf alpine-; fi; uname -m" [2023-03-21 17:30:19.751] Unable to detect if server is already installed: Error: Command failed: C:\Windows\System32\wsl.exe -d Ubuntu-20.04 -e sh -c "if [ -d ~/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884 ]; then printf 'install-found '; fi; if [ -f /etc/alpine-release ]; then printf alpine-; fi; uname -m" [2023-03-21 17:30:19.751] <3>WSL (886) ERROR: CreateProcessEntryCommon:523: initgroups failed 5 [2023-03-21 17:30:19.751] <3>WSL (886) ERROR: CreateProcessEntryCommon:583: Create process not expected to return [2023-03-21 17:30:19.751] [2023-03-21 17:30:19.751] [2023-03-21 17:30:19.751] ㌼圾䱓⠠㠸⤶䔠剒剏›牃慥整牐捯獥䕳瑮祲潃浭湯㔺㌲›湩瑩牧畯獰映楡敬⁤ਵ㌼圾䱓⠠㠸⤶䔠剒剏›牃慥整牐捯獥䕳瑮祲潃浭湯㔺㌸›牃慥整瀠潲散獳渠瑯攠灸捥整⁤潴爠瑥牵੮ [2023-03-21 17:30:19.751] Launching C:\Windows\System32\wsl.exe -d Ubuntu-20.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" ee2b180d582a7f601fa6ecfdad8d9fd269ab1884 stable code-server .vscode-server --host=127.0.0.1 --port=0 --connection-token=2937564942-4066959655-1976254933-2532570443 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all' [2023-03-21 17:30:20.124] <3>WSL (889) ERROR: CreateProcessEntryCommon:523: initgroups failed 5 [2023-03-21 17:30:20.124] <3>WSL (889) ERROR: CreateProcessEntryCommon:583: Create process not expected to return [2023-03-21 17:30:20.361] VS Code Server for WSL closed unexpectedly. [2023-03-21 17:30:20.361] For help with startup problems, go to https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips [2023-03-21 17:30:20.369] WSL Daemon exited with code 0

"Agency corrupted?" "Violating integrity?"

First things first: your issue is related to your host. You either have malfunctioning hardware (failing chipset, broken storage, power fluctuations) or something is real janky with your host OS. What makes it apparent is that your "disappearing files" are obviously caused by the device storing them no longer being attached to the path they are meant to be at. Coupled with the PEB corruption happening at the same time, and it's very obvious that the memory and/or IO virtualization suffers a stroke. And that is done in hardware.

Now that's taken care of: you may want to step away from the computer for some time and get some proper sleep and social stimulance, because you honestly don't sound like you're well :|

its easier to say his hardware is failing or malfunctioning rather to admit that docker desktop (WSL2) is broken since 3 years AGO!!!!! Btw this discussion could be closed because the bug is still there and no one is going to fix near soon, I'm waiting for the memory leak fix YEARSSS, not days, not months... YEARS since 2020 its the same problem, same people complaining... no fix. Install docker inside wsl2 manually or use hyper v resource hungry workaround. Other fixes are just useless and may cause data corruption due to ram being filled infinitely

@samuk190 WSL is a service provided by the operating system, and has never had any dependencies on docker. Most users don't have docker installed as it doesn't ship ship Windows, so they would have to download and install it themselves. And yet they have WSL, fully usable.

Docker can, and in most cases SHOULD, be configured to use WSL to run the docker daemon on, in which case it gets its own minimal linux installation where the daemon services run. Is dockerd where you're saying there's a memory leak? Nothing appears to leak anything, in any ring, and even if it does the worst that can happen is that the daemon goes down.

There is one way though, that WSL could possibly cause corruption on devices attached through docker. It would require that you, on purpose, attach to the instance used for wsl integration by docker, and start running things there. If you, for example, manage to convince vscode to set up a wsl remote development node there I am pretty confident you will break all sorts of things, by overwriting mountpoints etc. If that is indeed what you or the OP have managed do, then I agree, it's not a hardware error. It's not a bug either, if so, but rather similar to prying open your microwave oven because it looks similar to a a cage, set your pet gerbil loose in there, and when all of a sudden the corn stops popping you get mad at Siemens because your gerbil is leaking over your popcorn.

Tl;dr: a theory involving rodents and microwaves actually makes more sense than what you're saying. If you believe you have found a bug, write a bug report with a factual description of the behavior you observer. Avoid making up your own phrases and imaginary system designs, and above all: refrain from screaming these theories directly at the people that try and help you to get your completely free-of-charge development working again.

😀

@the-exodus

I said WSL because when you install docker desktop it says WSL2 is recommended, I did not say WSL2 is broken, I said DOCKER DESKTOP is broken which is a complete different thing. I use daily intellij inside WSL2 with apache tomcat and all my other stuff with no problem for months.

The problem here doesnt happen with me, it happened with TWO other friends and he had clean windows installation, I tried everything to debug or see what was causing the memory leak, but the SAME IMAGE, SAME SETTINGS, on Hyper V mode it DIDNT HAPPEN THE MEMORY LEAK. I'm 100% SURE DOCKER DESKTOP (WITH WSL2 ENGINE) IS BROKEN also you are misleading people by recommending to use with wsl2, " and in most cases SHOULD, be configured to use WSL to run the docker daemon on, ".

Answering your question, yes the problem it is inside DOCKERD(back-end of docker desktop) because I tried rancher desktop with DOCKERD and it happened same problem. Something is wrong between DOCKERD and WSL2.

(this problem does not happen if you install Dockerd inside wsl without any external connection)

and I will repeat: THIS BUG IS NOT NEW, IT IS HAPPENING YEARS AGO that was the main reason I've changed to linux in the past.

How did you diagnose the memory leak? Like, how did you identify that there is one?

Hi, any news on this ticket? We, as a team, are all facing similar issues in every Windows 10 with Ubuntu 22.0.4 in WSL2.

How did you diagnose the memory leak? Like, how did you identify that there is one?

It has been fixed on pre-releases using [experimental] autoMemoryReclaim=dropcache

@TEX910

microsoft / WSL