Debugger stopped working when installing 1.74 in MacOS Ventura

[robertohuertasm]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.74
• OS Version: MacOS Ventura 13.0.1

Steps to Reproduce:

1. Open my TypeScript project
2. Set some breakpoints
3. The breakpoints are enabled
4. The breakpoints are not hit

Other things I've tested:

• I've tested this with Insiders and VSCodium 1.74. The issue is always present.
• I've tested this with VSCode < 1.74, and the debugger starts to work again.
• I've tested this with VSCode 1.74 in Monterrey and it works.
• I've tested this with another project and it works. The main difference I can see is that the one that works is not running from bundled code.

I'll try to update this issue with some project I can share exposing this behavior.

[iurylippo]

I have a nestjs typescript project (docker) and I'm having the same problem, after upgrading to last release the debug stoped to working and is not disconnecting on clicking the button, I have to reload the vscode window.

Os: linux
testing same thing: vscode and vscode-insider both last releases

At the current moment using version: 1.73.1 and it worked perfectly.

[robertohuertasm]

I have more insights on the debugger behavior. It seems that it's only affecting breakpoints that are set at the beginning of the program's life cycle. It looks like the debugger is taking a lot of time to get active and by the time it's active, some breakpoints cannot be hit.

Not sure what changed in this version but in conjunction with MacOS Ventura made the debugger response time to grow. As I said, with the previous version in the same OS it works fine.

[robertohuertasm]

By the way, my machine is an M1 Max with 64GB.

[robertohuertasm]

Another thing I've noticed is that the project I'm trying to debug has two entries in the outFiles launch.json configuration entry. The moment I remove the second one, it works.

[robertohuertasm]

Interestingly, if I change this:

"outFiles": [
        "${workspaceFolder}/extension/.output.bundle/desktop/*.*",
        "${workspaceFolder}/extension/.output.bundle/frontend/*.*"
      ],

to

"outFiles": [
        "${workspaceFolder}/extension/.output.bundle/**/*.*",
      ],

it works again.

I'll keep this open in case the team wants to track this degradation in the debugging experience but I can at least debug now.

[robertohuertasm]

I can confirm that this same issue is affecting latest insiders version (1.75) in Windows 11 working with WSL.

[connor4312]

I'll keep this open in case the team wants to track this degradation in the debugging experience but I can at least debug now.

Thanks, will look at it.

[connor4312]

If you can share your logs as well, that would helpful:

/jsDebugLogs

[vscodenpa]

Please collect trace logs using the following instructions:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to [email protected]

[robertohuertasm]

Hi @connor4312. I just sent you an email with the js logs. Let me know if you need anything else.

[connor4312]

Thanks.

@andreamah / @roblourens this looks like a change or regression in the findTextInFiles API. Take the following sample code:

const disposable = vscode.commands.registerCommand('extension.helloWorld', async () => {
	const results: string[] = [];
	const glob = await vscode.window.showInputBox({ prompt: 'Glob pattern' });
	await vscode.workspace.findTextInFiles({ pattern: 'foo' }, {
		include: new vscode.RelativePattern(vscode.workspace.workspaceFolders![0], glob!),
	}, r => results.push(r.uri.toString()));
	vscode.window.showInformationMessage(JSON.stringify(results));
});

...and a workspace with files a/hello.txt and b/hello.txt both containing foo. Entering a glob for a/*.* or b/*.* will work, but a/*.*, b/*.* will return no results.

This is not the first issue about how globs get combined--would this be easier to deal with if the API took an array of glob patterns instead of requiring the consumer to combine them? As a stopgap I could have js-debug issue separate findTextInFiles calls for each glob, but this is suboptimal, and other consumers will hit this if/when the API is stable.

[andreamah]

Was a/*.*, b/*.* working in 1.73? I tried the same code in with 1.73 and got the same result.

[andreamah]

I also tried it with 1.68 (from quite a while ago) and I wasn't able to see it working there either?

[connor4312]

Yea, I'm not sure whether this is a regression or not.

[andreamah]

Did you use comma-separated globs previously and it worked?

[connor4312]

I believe it did at one point, or perhaps in some circumstances, though it's always been a little hit and miss. Maybe they were just 'accidentally' supported in the way things got passed into ripgrep.

[andreamah]

From what I'm seeing, the API assumes that there is only one glob assigned to include. For the case where you want to match two globs, we have internal support for that (ie: with the search viewlet), but I don't think there's a clear way to do it with the API (as you probably saw before).

Instead of passing in comma-separated globs, perhaps allowing include to be GlobPattern | GlobPattern[] would help? I was originally thinking that we could keep doing comma-separated values, but I think that search does extra work with the input paths to generate the actual paths that ripgrep uses (

vscode/src/vs/workbench/services/search/node/ripgrepTextSearchEngine.ts

Line 498 in ab1a31a

export function spreadGlobComponents(globArg: string): string[] {

)

I'm not too sure what behavior you were seeing before with the comma-separated system working?

[roblourens]

In grooming, I saw #104889, is that the same?

[connor4312]

Probably can be merged, will close it

allowing include to be GlobPattern | GlobPattern[] would help?

Would be great!

[robertohuertasm]

FYI, I cannot reproduce the issue anymore with the latest v1.74.1 update.

[iurylippo]

@connor4312 I sent a email with my log trace that just test again and still having problem with version 1.74.1

[iurylippo]

My exact text file on launch:

{
    "version": "0.2.0",
    "configurations": [

      {
        "name": "Docker: Attach to Node",
        "type": "node",
        "request": "attach",
        "address": "localhost",
        "port": 9229,
        "sourceMaps": true,
        "restart": true,
        "localRoot": "${workspaceFolder}",
        "remoteRoot": "/home/node",
        "outFiles": [
            "${workspaceFolder}/dist/**/*.js"
        ],
        // "outFiles": [],
        "skipFiles": [
          "<node_internals>/**",
          "${workspaceFolder}/node_modules/**"
        ],
        // "resolveSourceMapLocations": null,
        // "runtimeExecutable": null,
        // "stopOnEntry": false
        
      }
    ]
  }

[connor4312]

@iurylippo your issue is not related to this; please open a new issue. Also, the log you sent is truncated.

[connor4312]

I was touching glob stuff for a related issue, so I have also taken the workaround in microsoft/vscode-js-debug#1486 which seems to work. But once this gets fixed I can move back to the single glob run and just do some mutations instead.

[andreamah]

From what I'm seeing, the API assumes that there is only one glob assigned to include. For the case where you want to match two globs, we have internal support for that (ie: with the search viewlet), but I don't think there's a clear way to do it with the API (as you probably saw before).

Instead of passing in comma-separated globs, perhaps allowing include to be GlobPattern | GlobPattern[] would help? I was originally thinking that we could keep doing comma-separated values, but I think that search does extra work with the input paths to generate the actual paths that ripgrep uses (

vscode/src/vs/workbench/services/search/node/ripgrepTextSearchEngine.ts

Line 498 in ab1a31a

export function spreadGlobComponents(globArg: string): string[] {

)
I'm not too sure what behavior you were seeing before with the comma-separated system working?

Thinking about this, I think that something like {a/*.*, b/*.*} should ideally work, since it's a valid glob. I saw #38545, which showed that we considered an array of globs as input for FindFiles at a certain point in time, but didn't end up doing that. Therefore, the proper way to search multiple globs should be using the {...} notation. Created #169422 to track this.

[beezen]

The previous version is okay, but it cannot be broken after the upgrade.Always remind that no source file corresponding to SourceMap is found.

View which scrips are being loaded through the debug diagnostics tool, and the corresponding source file resources cannot be found.

[todor-a]

Are there any updates here? I'm still experiencing this. (Workaround was to download a previous release and use that instead.)

Thank you.

[beezen]

The previous version is okay, but it cannot be broken after the upgrade.Always remind that no source file corresponding to SourceMap is found.

View which scrips are being loaded through the debug diagnostics tool, and the corresponding source file resources cannot be found.

I happened to find that my colleague's configuration could be debugable. After comparison, only "workspaceFolder": "." was found. After the difference of this field was added, it could indeed be debugable。

[andreamah]

merging with #169422, which is the root cause. For now, the js debugger should have a fix for this on the user side.