Build output stucks in terminal

[alekseyt]

• VSCode Version: Code 1.19.1 (0759f77, 2017-12-19T09:41:01.414Z)
• OS Version: Linux x64 4.4.0-104-generic (Ubuntu 14.04.5)
• Extensions:

Extension	Author (truncated)	Version
gitlens	eam	7.2.0
nightswitch-lite	gha	2.0.3
Go	luk	0.6.70
cpptools	ms-	0.14.5
shader	sle	1.1.2
cmake	twx	0.0.17
code-navigation	vik	0.2.0
vscode-todo-highlight	way	0.5.11
lua-for-vscode	xxx	0.0.23

(1 theme extensions excluded)

---

Steps to Reproduce:

1. Start build (Run Build Task)
2. Observe terminal output

Result 1: terminal output hangs somewhere during build process (doesn't always reproduce)
Result 2: actual build continues in background ("Building..." appears in status bar, then disappears after some time)

3. Repeat steps 1-2

Result 3: terminal output doesn't change, it stays in "hanged" state from previous build
Result 4: build presumably executes in background, "Building..." appears in status bar, just no output in terminal

Reproduces without extensions: Yes/No

I'm using multithreaded CMake build with ccache. Issue reproduces more or less stably when i'm rebuilding my project in different configurations (Debug/Release). My tasks.json:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "build",
            "type": "shell",
            "command": "make -j 4",
            "options": {
                "cwd": "${workspaceRoot}/build"
            },
            "presentation": {
                "reveal": "silent"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        }
    ]
}

Point where output hangs is always on printing a warning from GCC (4.8.5). It goes like this:

1. Multithreaded build starts
2. Output from parallel jobs is mixed in terminal (that's fine)
3. Build comes to the point where warning is printed
4. At point 3 terminal might or might not hang

Surprisingly it's always the very same warning from very same file where output hangs: warning: ‘...[skip]...’ defined but not used [-Wunused-function]. If it hangs, i've found two workarounds to "unstuck" terminal:

1. Restart vscode
2. Click on terminal window and press Enter. After this build output disappears, terminal switches to shell and i can restart build again normally, with build output correctly appearing on screen.

Additional info: i'm using ccache, so build doesn't recompile objects but gets them from cache instead. All parallel build jobs are executed very fast on cache, like 10-20 objects are "compiled" per second, so i suspect it's some sort of race condition. When i try to reproduce this issue i have to do 3-5 tries, but it does always reproduce after relatively small number of attempts.

[alekseyt]

I've done some experimenting with extension and i can't reproduce this issue with all extensions disabled. If i reenable C/C++ extension then issue comes back, so "Reproduces without extensions: No". I'll report this issue to vscode-cpptools.

[pieandcakes]

We aren't doing any processing for the build scenario in the C/C++ extension. If someone with VSCode can point me to where I can look to see what is causing it with the extension enabled, that would be appreciated.

[alekseyt]

I tried to find some more debug info on this and found Help->Toggle Developer Tools. This is what printed to JavaScript console when this happens:

Line 1:

[uncaught exception]: URIError: URI malformed
onError	@	index.js:38
(anonymous)	@	index.js:98
emitOne	@	events.js:96
emit	@	events.js:191
window.onerror	@	/usr/share/code/resources/electron.asar/renderer/init.js:135
i.globals.onerror	@	errorTelemetry.ts:64

Line 2:

URIError: URI malformed   index.js:41
    at decodeURIComponent (<anonymous>)
    at Function.e.parse (uri.ts:222)
    at v (problemMatcher.ts:174)
    at t.e.getResource (problemMatcher.ts:255)
    at t.e.getMarkerMatch (problemMatcher.ts:247)
    at t.handle (problemMatcher.ts:343)
    at t.e.tryMatchers (problemCollectors.ts:170)
    at t.e.tryFindMarker (problemCollectors.ts:133)
    at t.processLine (problemCollectors.ts:333)
    at terminalTaskSystem.ts:312
    at terminalInstance.ts:870

Line 3:

Uncaught URIError: URI malformed   uri.ts:222
    at decodeURIComponent (<anonymous>)
    at Function.e.parse (uri.ts:222)
    at v (problemMatcher.ts:174)
    at t.e.getResource (problemMatcher.ts:255)
    at t.e.getMarkerMatch (problemMatcher.ts:247)
    at t.handle (problemMatcher.ts:343)
    at t.e.tryMatchers (problemCollectors.ts:170)
    at t.e.tryFindMarker (problemCollectors.ts:133)
    at t.processLine (problemCollectors.ts:333)
    at terminalTaskSystem.ts:312
    at terminalInstance.ts:870

I suspect this is somehow related to parallel jobs outputting to terminal concurrently (make -j 4). Not sure how this is related to enabling/disabling C/C++ extension.

[Tyriar]

Looks like it's related to tasks/problem matchers

[pieandcakes]

@sean-mcmanus Can you take a look and see where the task/problem matchers are causing this issue?

[sean-mcmanus]

Yeah we contribute the gcc problem matcher. I notice that it's still referencing ${workspaceRoot} instead of ${workspaceFolder}, but I'm not sure if that's the cause of the hanging issue.

https://github.com/Microsoft/vscode-cpptools/blob/master/Extension/package.json

`
"problemMatchers": [

  {

    "name": "gcc",

    "owner": "cpptools",

    "fileLocation": [

      "relative",

      "${workspaceRoot}"

    ],

    "pattern": {

      "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",

      "file": 1,

      "line": 2,

      "column": 3,

      "severity": 4,

      "message": 5

    }

  }`

[dbaeumer]

@Tyriar there seems to be a problem with the terminal as well. If a listener on the data event of the terminal throws the terminal should not get into a broken state. I will look into handling this in the problem matcher as well however the terminal should protect itself too.

[dbaeumer]

I don't know why but the problem matcher seems to match a line where the file part doesn't correspond to a valid file hence resulting in throwing when we try to convert to an URI.

[dbaeumer]

Added protection code for the problem matcher. @Tyriar assigning to you to do the same for the terminal.

[roblourens]

Verification steps?

[dbaeumer]

@roblourens best would be to do a code review / inspection. I didn't have any steps either but concluded the problem from the provided stack traces here: #41165 (comment)