VS Code becomes unresponsive inside Docker container

[davefinster]

• VSCode Version: 1.19.3
• OS Version: 4.13.0-32-generic [extension] resolving a completion items is call twice for the first selected item in the list #35-16.04.1-Ubuntu SMP

Steps to Reproduce:

1. Open VS Code to my current project (reasonable C++ project)
2. Right click on a symbol and select "Show Declaration"
   VS Code becomes unresponsive with this printed in the console (running --verbose)

Server response: <?xml version="1.0" encoding="UTF-8"
[VS Code]: detected unresponsive

Does this issue occur when all extensions are disabled?: Yes - produces this output and crashes immediately upon launch.

To provide some background, this instance of VS Code is running inside a Debian docker container with the following parameters:

docker run --net=host --name container -i -t -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix --privileged --restart unless-stopped <image-name>

I'm not sure how to debug this further and determine why VS Code has become unresponsive.

[kdkeyser]

I run into the same issue. Behaviour seen both with C++ as well as a Haskell project, so likely unrelated to the plugins. Same project/plugins running natively (so not in docker) works fine.

[weinand]

This issue was moved to microsoft/vscode-cpptools#1610

[sean-mcmanus]

@weinand We don't think this is a vscode-cpptools issue. The user is reproing it without any extensions installed.

[bpasero]

@chrisdias @chrmarti did you ever run VS Code like that in a docker container?

[chrmarti]

No. Some of the later errors are related to the GPU (or its absence). Try running with --disable-gpu and let us know what the output is.

[davefinster]

Apologies for the delay in responding. The output from code --verbose --disable-gpu can be found here

[chrmarti]

I see ENOSPC in there, try these instructions: https://code.visualstudio.com/docs/setup/linux#_error-enospc

[davefinster]

Just increased the watch limit and while those errors disappeared, the same issue has reoccured.

The last two lines of the console output were:

Server response: <?xml version="1.0" encoding="UTF-8"
�[91m[main 2:09:42 AM]�[0m [VS Code]: detected unresponsive

as before. Full output is here

[chrmarti]

Not sure who tried, but I think someone had it running in Docker. @Tyriar ?

[davefinster]

So something interesting I just observed - I attempted to toggle developer tools within VS Code to see if I could get a timeline or any other info when a hang occurred. When I triggered the developer tools, the window would appear but as soon as I moved my mouse out of the dev tool area, it went blank with a background the same colour as the rest of the window.

The log output is available here but I did notice the following:

[1773:0303/005920.516068:WARNING:x11_util.cc(1360)] X error received: serial 3959, error_code 3 (BadWindow (invalid Window parameter)), request_code 3, minor_code 0 (X_GetWindowAttributes)
[1773:0303/005920.516181:WARNING:x11_util.cc(1360)] X error received: serial 4019, error_code 3 (BadWindow (invalid Window parameter)), request_code 3, minor_code 0 (X_GetWindowAttributes)
[1773:0303/005920.516192:WARNING:x11_util.cc(1360)] X error received: serial 4079, error_code 3 (BadWindow (invalid Window parameter)), request_code 3, minor_code 0 (X_GetWindowAttributes)

I then toggled the dev tools are few more times and it eventually caused VS Code to crash without a minidump.

[davefinster]

The lack of a minidump actually led me to this issue in the Atom project: atom/atom#8684

I've rebuilt the container while adding --ipc host -v /dev/shm:/dev/shm and I haven't had a hang yet. The dev tools still crash when toggled for the second time (but they don't disappear now).

The last comment on this issue does a better job of explaining it: cypress-io/cypress#350 - namely Docker has a default of 64MB of shared memory per container which is perhaps getting exhausted (since I"m running C++ extensions on a fairly large project) thereby causing a hang.

[Tyriar]

We never really supported this, it's a feature request imo. I've closed a similar issue in the past as out of scope #27284 when we cleaned up the backlog.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!