Watch causes VS Code to crash.

[cwoolum]

Describe the bug
If I try to use this extension while using a SSH remote connection, VSCode will crash and restart.

To Reproduce
Steps to reproduce the behaviour:

1. Open a project in a SSH remote environment.
2. Select any TS or JS file and right click it.
3. Select Watch or Display Coverage.
4. The spinner will keep loading. According to the logs, 2 files are found.
5. The last log message avilable is

[1621925153079][coverageservice]: INITIALIZING
[1621925153483][coverageservice]: LOADING
[1621925153493][coverageservice]: Loading 2 file(s)

I added some additional logging and it seems that both files are loaded but loadDataFiles never seems to return and the next logger line [coverageservice]: Loaded never gets hit.

Expected behaviour
I would expect the code coverage to load correctly.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows, Code is SSH to Ubuntu
• 2.7.3
• VSCode Version 1.57.0

Additional context
Add any other context about the problem here.

[ryanluker]

@cwoolum Thanks for submitting a ticket!
I will do a bit more triage later but I think it might be coming from the fact that the loadFile is probably not able to interact over the ssh remote connection 🤔 . Most of the time vscode runs some extensions on the vscode server (see https://code.visualstudio.com/docs/remote/ssh for some diagram details) if they require access to files locally.

Can you debug some of the file names and see if those existing on the host or client machine?

    /**
     * Takes files and converts to data strings for coverage consumption
     * @param files files that are to turned into data strings
     */
    public async loadDataFiles(files: Set<string>): Promise<Map<string, string>> {
        // Load the files and convert into data strings
        const dataFiles = new Map<string, string>();
        for (const file of files) {
            dataFiles.set(file, await this.load(file));
        }
        return dataFiles;
    }
    
    private load(path: string) {
        return new Promise<string>((resolve, reject) => {
            readFile(path, (err, data) => {
                if (err) { return reject(err); }
                return resolve(data.toString());
            });
        });
    }

You may be able to fix this by using the manual coverage file paths feature to provide the exact file path 🤔

        "coverage-gutters.manualCoverageFilePaths": {
          "type": "array",
          "default": [],
          "description": "take manual control over the absolute path to your coverage file(s)"
        },

[cwoolum]

Hey @ryanluker,

All of the files are on the client machine. The extension is able to resolve them and I can log the content of them but for some reason nothing seems to happen after loadDataFiles. As far as I can tell, load is working correctly.

[Jason3S]

@ryanluker,

This is also happening to me, only I have everything local. No remote files involved.

In my case, I have a multi-root setup. Each workspace folder can have its own ./coverage/ directory.

[ryanluker]

@Jason3S thanks for the extra info! can you confirm you are able to use the example projects workspace / multi-root setup?
https://github.com/ryanluker/vscode-coverage-gutters/blob/master/example/example.code-workspace

You might need to define a default folder or some other tweak for it to work 🤔.

[FizzBuzz791]

I've noticed this issue occur when using WSL2 in the last few weeks. Eventually, it seems like the whole plugin platform crashes.: Angular, ESLint, etc., plugins all have to reload. Hasn't been an issue previously, but I've no clue what's changed.

[Jason3S]

@FizzBuzz791,

VS Code has been very unstable over the past few weeks. By default, I don't have this extension enabled, and I see the same thing.

Please open (or add to) and issue against VS Code.

[FizzBuzz791]

@Jason3S - VS Code itself has been perfectly stable for me, it's only when I try to run the "Display Coverage" and/or "Watch" command that the entire extensions runner system crashes and all my extensions have to reload. That's definitely a bug with this extension and not VS Code.

I've also tried the manual coverage file paths workaround but even when I use the fully qualified path (e.g. \\wsl.localhost\Ubuntu\home\<username>\path\to\my\coverage\file) it says it can't be found.

[Jason3S]

@FizzBuzz791,

That sounds like an issue with this extension. I suggest opening a new Issue. This one is a bit stale and might be unrelated.

[ryanluker]

@FizzBuzz791 @Jason3S Thanks for the discussion on this ticket!
Definitely, you could open a new ticket or use this one. Either way, please also attach a debug log, so we can figure out where the crash is coming from 🤔.

(see comment below on where to find the debug logs)
#389 (comment)

[FizzBuzz791]

Sorry @ryanluker, I think I missed your reply on this one.

I opened the Output tab, cleared the logs for "Extension Host (Remote)" and then ran the "Display Coverage" command and this is what I got.

2023-07-11 16:09:37.035 [info] Extension host with pid 1934 started
2023-07-11 16:09:37.035 [error] Error: EEXIST: file already exists, open '/home/trentj/.vscode-server/data/User/workspaceStorage/87bfc90ab825324ce3afd4c2046e3948/vscode.lock'
2023-07-11 16:09:37.046 [info] Lock '/home/trentj/.vscode-server/data/User/workspaceStorage/87bfc90ab825324ce3afd4c2046e3948/vscode.lock': Could not acquire lock, checking if the file is stale.
2023-07-11 16:09:37.066 [info] ExtensionService#_doActivateExtension vscode.emmet, startup: false, activationEvent: 'onLanguage'
2023-07-11 16:09:37.067 [info] ExtensionService#_doActivateExtension vscode.css-language-features, startup: false, activationEvent: 'onLanguage:scss'
2023-07-11 16:09:37.067 [info] ExtensionService#_doActivateExtension vscode.json-language-features, startup: false, activationEvent: 'onLanguage:jsonc'
2023-07-11 16:09:37.067 [info] ExtensionService#_doActivateExtension vscode.typescript-language-features, startup: false, activationEvent: 'onLanguage:jsonc'
2023-07-11 16:09:37.068 [info] ExtensionService#_doActivateExtension eamodio.gitlens, startup: false, activationEvent: 'onView:gitlens.views.remotes'
2023-07-11 16:09:37.068 [info] ExtensionService#_doActivateExtension mhutchie.git-graph, startup: false, activationEvent: 'onCommand:git-graph.view'
2023-07-11 16:09:37.068 [info] ExtensionService#_doActivateExtension vscode.git-base, startup: false, activationEvent: 'onFileSystem:git', root cause: vscode.git
2023-07-11 16:09:37.069 [info] ExtensionService#_doActivateExtension ms-vscode.live-server, startup: false, activationEvent: 'onCommand:coverage-gutters.displayCoverage', root cause: ryanluker.vscode-coverage-gutters
2023-07-11 16:09:37.069 [info] ExtensionService#_doActivateExtension dbaeumer.vscode-eslint, startup: false, activationEvent: 'onCommand:eslint.showOutputChannel'
2023-07-11 16:09:37.352 [info] Lock '/home/trentj/.vscode-server/data/User/workspaceStorage/87bfc90ab825324ce3afd4c2046e3948/vscode.lock': The pid 1419 appears to be gone.
2023-07-11 16:09:37.352 [info] Lock '/home/trentj/.vscode-server/data/User/workspaceStorage/87bfc90ab825324ce3afd4c2046e3948/vscode.lock': Deleting a stale lock.
2023-07-11 16:09:37.370 [info] Lock '/home/trentj/.vscode-server/data/User/workspaceStorage/87bfc90ab825324ce3afd4c2046e3948/vscode.lock': Lock acquired.
2023-07-11 16:09:37.560 [info] ExtensionService#_doActivateExtension vscode.git, startup: false, activationEvent: 'onFileSystem:git'
2023-07-11 16:09:37.560 [info] ExtensionService#_doActivateExtension ryanluker.vscode-coverage-gutters, startup: false, activationEvent: 'onCommand:coverage-gutters.displayCoverage'
2023-07-11 16:09:38.170 [info] ExtensionService#_doActivateExtension vscode.github, startup: true, activationEvent: '*'
2023-07-11 16:09:38.170 [info] ExtensionService#_doActivateExtension EditorConfig.EditorConfig, startup: true, activationEvent: '*'
2023-07-11 16:09:38.171 [info] ExtensionService#_doActivateExtension ms-vscode.test-adapter-converter, startup: true, activationEvent: '*', root cause: hbenl.vscode-test-explorer
2023-07-11 16:09:38.297 [info] ExtensionService#_doActivateExtension vscode.npm, startup: true, activationEvent: 'workspaceContains:package.json'
2023-07-11 16:09:38.361 [info] ExtensionService#_doActivateExtension hbenl.vscode-test-explorer, startup: true, activationEvent: '*'
2023-07-11 16:09:38.436 [info] ExtensionService#_doActivateExtension kavod-io.vscode-jest-test-adapter, startup: true, activationEvent: '*'
2023-07-11 16:09:39.039 [info] Eager extensions activated
2023-07-11 16:09:39.039 [info] ExtensionService#_doActivateExtension vscode.debug-auto-launch, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.039 [info] ExtensionService#_doActivateExtension vscode.merge-conflict, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.040 [info] ExtensionService#_doActivateExtension esbenp.prettier-vscode, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.042 [info] ExtensionService#_doActivateExtension GitLab.gitlab-workflow, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.042 [info] ExtensionService#_doActivateExtension SonarSource.sonarlint-vscode, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.043 [info] ExtensionService#_doActivateExtension streetsidesoftware.code-spell-checker, startup: false, activationEvent: 'onStartupFinished'
2023-07-11 16:09:39.043 [info] ExtensionService#_doActivateExtension stylelint.vscode-stylelint, startup: false, activationEvent: 'onStartupFinished'

[ryanluker]

@FizzBuzz791 Thanks for those logs, I think we need different ones though 🤔 they should look like the ones below. Do a double check on the output tab that the top right dropdown is showing coverage gutters like in the image below.

[martijnhoutman]

I ran into the same issue when dealing with Cobertura coverage reports.

After some debugging, I found an issue in the cobertura-parse npm library. It parses an attribute called condition-coverage with a very simple regexp. I noticed that some of my Cobertura output has some special values for this attribute, e.g.:

<line number="88" hits="3" branch="true" condition-coverage="71.42857142857143% (5/7)"/>

The parsing of this attribute is currently done like so:

var branchStats = l.$['condition-coverage'].match( /\d+/g );

Due to the non-integer value of the percentages, the parsing goes wrong. It should however ignore the percentage, and just deal with the (dividend/divisor) part. The proper code for parsing would be:

var branchStats = /(\d+)\/(\d+)/g.exec(l.$['condition-coverage']);

However, the cobertura-parse package is no longer maintained, so fixing this would require a fork, and that fork to be included in this extension. Maybe the maintainers of this package have something to say about this?

The specs for Cobertura are somewhat lacking (https://github.com/cobertura/web/blob/master/htdocs/xml/coverage-04.dtd), so it is not really a wonder that these things happen.

[ryanluker]

I ran into the same issue when dealing with Cobertura coverage reports.

After some debugging, I found an issue in the cobertura-parse npm library. It parses an attribute called condition-coverage with a very simple regexp. I noticed that some of my Cobertura output has some special values for this attribute, e.g.:

<line number="88" hits="3" branch="true" condition-coverage="71.42857142857143% (5/7)"/>

The parsing of this attribute is currently done like so:

var branchStats = l.$['condition-coverage'].match( /\d+/g );

Due to the non-integer value of the percentages, the parsing goes wrong. It should however ignore the percentage, and just deal with the (dividend/divisor) part. The proper code for parsing would be:

var branchStats = /(\d+)\/(\d+)/g.exec(l.$['condition-coverage']);

However, the cobertura-parse package is no longer maintained, so fixing this would require a fork, and that fork to be included in this extension. Maybe the maintainers of this package have something to say about this?

The specs for Cobertura are somewhat lacking (https://github.com/cobertura/web/blob/master/htdocs/xml/coverage-04.dtd), so it is not really a wonder that these things happen.

Thanks for the investigation!

We use a custom fork already of the cobertura-parse and I think that fork is a bit more active if there is bugs or improvements needed 🤔.
https://github.com/fschwaiger/cobertura-parse/commits/master
@fschwaiger Might know more if we can make small improvements to it or not.