Mac crashes when searching on the sidebar search form.

[tarky17]

Issue Type: Bug

Type validation-> in the sidebar search form.

When entering one character at a time

As soon as you enter the> character, the mac hangs and the mac restarts. I tried it several times, but even if I didn't hang up, mac stopped and started moving for about 1 minute. In this case,> is input as many characters as validation->>>>>>>>>>>>>>>>>>>>.

When pasting validation-> string with copy and paste

Mac hangs up.

I think this bug did not occur before Ver1.40
Maybe related to #86913

VS Code version: Code 1.41.0 (9579eda04fdb3a9bba2750f15193e5fafe16b959, 2019-12-11T17:58:38.338Z) OS version: Darwin x64 18.7.0

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz (12 x 3200)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off
surface_control: disabled_off
surface_synchronization: enabled_on
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|3, 35, 30| |Memory (System)|16.00GB (0.58GB free)| |Process Argv|-psn_0_520319| |Screen Reader|no| |VM|0%|

Extensions (64)

Extension|Author (truncated)|Version ---|---|--- html-snippets|abu|0.2.1 vscode-caniuse|aka|0.5.3 Bookmarks|ale|10.6.0 project-manager|ale|10.9.1 vagrant|bbe|0.5.0 path-intellisense|chr|1.4.2 regex|chr|0.2.0 bracket-pair-colorizer-2|Coe|0.0.29 vscode-svgviewer|css|2.0.0 vscode-eslint|dba|2.0.6 vscode-dash|dee|2.3.0 githistory|don|0.4.11 jquerysnippets|don|0.0.1 gitlens|eam|10.2.0 EditorConfig|Edi|0.14.3 apacheconf-snippets|eim|1.3.0 LogFileHighlighter|emi|2.6.0 vscode-great-icons|emm|2.1.47 prettier-vscode|esb|3.16.1 vscode-todo-plus|fab|4.14.1 php-debug|fel|1.13.0 auto-close-tag|for|0.5.6 auto-rename-tag|for|0.1.1 code-runner|for|0.9.15 vscode-google-translate|fun|1.4.2 vue-snippets|hol|0.1.11 minify|Hoo|0.4.3 rest-client|hum|0.23.0 output-colorizer|IBM|0.1.2 plantuml|jeb|2.13.5 docthis|joe|0.7.1 markdownfromcsv|joj|1.0.0 vscode-insertdatestring|jsy|2.2.4 vscode-sshfs|Kel|1.16.3 vscode-regexp-preivew|le0|0.0.3 vue|liu|0.1.5 MagicPython|mag|1.1.0 rainbow-csv|mec|1.3.1 easy-less|mrc|1.5.1 vscode-apache|mrm|1.2.0 vscode-csscomb|mrm|5.3.0 vscode-docker|ms-|0.9.0 vscode-language-pack-ja|MS-|1.41.2 mssql|ms-|1.8.0 python|ms-|2019.11.50794 debugger-for-chrome|msj|4.12.3 indent-rainbow|ode|7.4.0 csv-to-table|php|1.2.1 material-icon-theme|PKi|3.9.2 partial-diff|ryu|1.4.0 vscode-sql-beautify|sen|0.0.4 code-settings-sync|Sha|3.4.3 addDocComments|ste|0.0.8 pretty-json|sup|0.0.4 ayu|tea|0.18.0 pdf|tom|0.5.1 highlight-matching-tag|vin|0.9.6 vscode-icons|vsc|9.6.0 quokka-vscode|Wal|1.0.267 jinja|who|0.0.8 change-case|wma|1.0.0 better-align|wwm|1.1.6 JavaScriptSnippets|xab|1.7.2 markdown-pdf|yza|1.4.1 (5 theme extensions excluded)

[tarky17]

Additional Information The search string will behave strangely with any string, not validation->. I guess the search function on the left side is abnormal.

I downgraded vscode to ver1.40.2 and tried the same procedure, but no bugs occurred. I confirmed that I can search normally with ver1.40.2.

Don't forget to turn off the automatic update function. Otherwise it will soon be 1.41.0.

[vincentcn]

Met the same issue.

Version: 1.41.0
Commit: 9579eda04fdb3a9bba2750f15193e5fafe16b959
Date: 2019-12-11T17:58:38.338Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 17.7.0

[LilaHickey]

Also experiencing this issue:

VSCode Version: 1.41.1 OS: Mac Mojave 10.14.6

Confirmed tarky17's experience that downgrading to 1.40.2 resolves the bug.

Note that this bug appears unaffected by modifications to User Preferences for Search (both "Exclude" and "Use Ignore Files") which are things I've seen people suggest changing on other similar bug reports.

Reporter alluded to this, but the bug feels related to debouncing the query - I don't encounter bugginess on the first search, but if I start to modify it before completion of search, VSC does not seem to wait for/honor pressing the "Enter" key but perhaps is searching immediately and after every keystroke.

[roblourens]

Can you try disabling search.searchOnType and see whether that helps in 1.41?

[tarky17]

@roblourens I have confirmed that this bug does not occur with search. SearchOnType disabled in ver1.41.1.

My env below.

Version: 1.41.1 Commit: 26076a4de974ead31f97692a0d32f90d735645c0 Date: 2019-12-18T14:57:51.166Z Electron: 6.1.5 Chrome: 76.0.3809.146 Node.js: 12.4.0 V8: 7.6.303.31-electron.0 OS: Darwin x64 18.7.0

[LilaHickey]

@roblourens same for me.

I gather this is a new feature in this release, as I don't see that settings option in 1.40.2?

I wonder if changing the default setting might be advisable? Several people I know have switched to another IDE out of frustration with this behavior, which is a shame if it's actually a feature.

[roblourens]

Yeah, it was new. So to be clear, when you have that setting enabled and type your query, you get the freeze, but when you disable it and type the same query and press enter, it doesn't freeze? FYI @JacksonKearl

Also, is anyone on MacOS Catalina?

[LilaHickey]

Hi Rob,

That's correct.

I did a quick ABA test to confirm this - reinstalled vsc@1.41.1, confirmed that searchOnType is enabled (w a debounce of 300ms, which I assume is the default), began to type a search string, and beachballed my Mac.

There is definitely some nuance to this behavior - I see different behavior when using different query strings/folder inclusion settings. I think the common thread is the total volume of results being generated by an in-flight query (or queries, not sure how that looks under the hood).

For example, in a TS project, typing "im" (on the way to searching for "import") is more likely to cause freezing than searching for "xyz"

Let me know if there's anything else I can do to help debug this.

[roblourens]

So is it a really large project, like would "im" return a ton of results? And if you disable search on type, then type "im" and press enter, it doesn't freeze?

It might help if you do this

• Run the command "Set log level" and change it to "Trace"
• Repro the issue
• Show the search-related messages in the "Log (Window)" output panel

That would show us how many times search is being triggered and why. That may or may not be useful info.

[LilaHickey]

I don't have a sense of what you would consider a lot, but "import" returns 8,000 results across 1,500 files, so... maybe?

Just searching for "im" hits the 10,000 result limit/instruction to narrow the search, so presumably there are considerably more matches for that substring.

I went back and tested "im" on both 1.40.2, and 1.41.1 with searchOnType disabled, and I can sometimes* but not always cause freezes. With searchOnType enabled in 1.41.1 the freeze occurs 100% of the time.

So it seems that the issue is not a problem with the search on type feature, per se, but rather that it exposes an underlying limitation of the search functionality against a repo of our size. Still, not a great UX from our perspective :(

• I can't figure out the pattern yet in why this behavior isn't consistent; maybe caching of some sort?

Sadly, while I can attempt to capture those logs, they don't survive the hard reboot required to recover my machine after reproducing the behavior 🤷‍♀️

[roblourens]

with searchOnType disabled, and I can sometimes* but not always cause freezes

Thanks for the investigation, this is really the root of it I think. Something about having ripgrep return a ton of results can cause this, and starting/cancelling multiple searches quickly probably makes it worse. One more thing, could you try disabling search.followSymlinks? It has led to perf issues before and if you have a lot of symlinks in your workspace then this might help.

[fastfading]

search.followSymlinks did not help

[fastfading]

Version: 1.41.1 Commit: 26076a4de974ead31f97692a0d32f90d735645c0 Date: 2019-12-18T14:57:51.166Z Electron: 6.1.5 Chrome: 76.0.3809.146 Node.js: 12.4.0 V8: 7.6.303.31-electron.0 OS: Darwin x64 19.2.0

[LilaHickey]

@roblourens we don't do any symlinking that I'm aware of in this project, but I tested the combination of searchOnType: enabled & followSymlinks: disabled for the dreaded "im" search string, and still saw a freeze.

Also, something occurred to me with regards to the intermittency of the freeze that I was describing in yesterday's comment: would these kind of Settings changes require a restart of the app before they take effect?

[roblourens]

Ok, it was just a guess.

would these kind of Settings changes require a restart of the app before they take effect?

No, not these

[roblourens]

I have looked into this a few times and have never been able to repro any issue, I am able to use searchOnType and start multiple searches in a large workspace one after another with no issues at all, on my 2016 macbook.

There are some things that I think I am not sure about

• When this is happening, do you see multiple rg processes? Would show up as /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/node_modules.asar.unpacked/vscode-ripgrep/bin/rg in the Process Explorer or code --status
• Do you see any other vscode-related processes using high cpu?
• Also, the logs that I mentioned earlier might still be helpful - https://github.com/microsoft/vscode/issues/87254#issuecomment-571820487 if needed you can check the path of the log file before starting to reproduce the issue, it should survive a reboot if needed
• I wonder whether there are any other factors, do you have low memory available, other processes busy when this is happening, is it an older Mac, etc?

[cephalization]

I will attempt to repro again this week. Issue has not occurred again since disabling searchOnType. I am running on a new 16" mbp with hardly nothing else installed and I am working in a javascript react git repo with around 1800 files.

[roblourens]

If you are still able to repro it, could you share the repo so I can try with the exact same setup?

[cephalization]

I’ll have to try it against some of my public repos, the one I first hit this issue on is private

[LilaHickey]

Hey Rob,

I've upgraded to 1.42.1, and even with searchOnType turned on, I've not been able to recreate the freeze. (I assume we don't expect anything to have fixed this between 1.41.1 and 1.42.1 but if you think it's worth rolling back to the original version let me know.)

My Mac is pretty modern (2017, 3.1 GHz Intel Core i7), but your question got me thinking - I do frequently run Docker, which has intermittent performance spiking problems on its own. I can certainly see the combo causing a total freeze, if they happened simultaneously.

I will leave 'searchOnType' turned on, in hopes of being able to raise it organically, but let me know if you think rolling back to 1.41.1 is also worth doing for testing purposes.

[roblourens]

That's interesting, I'll try to repro this with some containers running.

No need to downgrade, but please let me know how it goes with searchOnType enabled, thanks!

[LilaHickey]

Hey Rob,

I'm not sure what I'm currently seeing is the same root cause as this bug (because I have searchOnType turned off), but I'm now encountering multiple search-triggered beachballs per day. I will add a follow-up comment with more data if/as I do a little more sleuthing and decide if this is relevant to the current thread.

Meanwhile - I am reviewing my logs in hopes of getting more data, but I'm curious what determines the number of simultaneous render logs/whether this is normal(ish)?

[roblourens]

Hm, I don't think I've seen that format before but it's probably not a problem. We try to pick window IDs to be simple and increasing but can probably lose count somehow...

[surajbarkale]

I have reliably encountered this when searching for callPackage in https://github.com/NixOS/nixpkgs master checkout with searchOnType enabled. I do not have any time to investigate this further.

[vivekme]

Hi Rob, The searchOnType is disabled but it is not taking effect in the file/folder filter. It still does search on type and freezes the Mac. Can you please enable that option for filter box as well? This workaround will mostly solve the freeze for me.

[chrisgordon]

FYI, disabling searchOnType did not fix the issue for me. It can still cause a freeze once I do anything that interrupts/restarts a search (eg. hit Enter, change case or word options, click Clear to abort).

[gclements-chwy]

I uninstalled a couple plugins and haven't had a crash/freeze in a couple days. IIRC they were the Microsoft C/C++ plugin and the Deno plugin.

[david9991]

Exactly same issue here. @roblourens I think it will be easier to reproduce by:

1. Add LLVM, Golang, ... many large projects to one workspace.
2. Reach a single character a in sidebar to produce many search results.
3. It will finally freeze the macOS.

I have 20 projects in a single workspace (incl. LLVM, Golang), it's 100% reproducible here.

[jxramos]

I first started seeing this error after upgrading to the Microsoft C++ extension which recently jumped to a 1.0 release. I found that I can reproduce the hang consistently on one of my repo clones but not another clone. Anyone with some debug tips they'd like me to try I can take a moment and experiment on that. Since mine reproduces on command we might be able to find something out.

[zgramana]

I have been running into this issue on my 16" MBP (macOS 10.15.6), and the cause is always the same: an unconstrained search of a workspace with 5+ projects each with between 6k - 15k files each. By unconstrained, I mean not limiting search results by using a filter/glob in the files to include input field. The amount of search results normally returned doesn't matter, only seemingly searching all projects at once.

It is not 100% reproducible (though given the impact, I don't spend any time trying to narrow things down). Sometimes the unconstrained search works as expected, but usually I find that out by lucky accident. I know immediately when I've hit it, as the search quickly triggers the spinning beachball of death, the system is unresponsive (so no ability to use system/diagnostic tools to kill the proc), then around 30 seconds the fans kick in, and finally the automatic reboot.

I have never had the issue with a filter that constrains the search to one specific project in my workspaces (e.g. ./foo-project.

The reboot happens as a result of the macOS watchdog timing out on it's kernel health check. Seeing the timeout, it reboots the machine. This can be verified in the logs (e.g. panic-full-xxxx.ips under "Log Reports" in Console):

"macOSPanicString" : "panic(cpu 10 caller 0xffffff7f879a1a8d): watchdog timeout: no checkins from watchdogd in 96 seconds (309 total checkins since monitoring last enabled)

Per this thread, I had previously disabled "Fast Graphics Switching" and hadn't encountered this issue in a while. I recently turned switching back on, having forgotten about this problem, and I hit it again today. This could well be coincidence, as I normally avoid unfiltered searches at all costs and simply may not have had "tests" during the window graphics switching was off.

Update: I tried an unfiltered search with "Fast Graphics Switching" turned on and hit the reboot pretty quickly. I then turned it off, rebooted (on purpose), and tried many unfiltered searches and could not reproduce the issue.

[LilaHickey]

My environment is a npm-oriented monorepo and due to some architectural concerns, there are node_modules directories at various different depths, i.e. not all easily caught by a single globbing pattern.

I was able to stop the hangs entirely by taking the time to build out the necessary glob patterns to exclude all my node_modules directories, which generally gels with other observations around unconstrained search, size of search space, etc.

[david9991]

Have 1.49.1 fixed this issue? I am not so sure, but seems not happen again here. 🤔 Recently, I

• upgraded safari to 14.0.
• Vscode upgraded to 1.49.1.
• Switched Surge's TLS engine from Network Framework to OpenSSL (The software mentioned that Network Framework could cause some freeze).
• Upgraded VMware Fusion to 12 Player (no kernel extension anymore?). Not sure what could fix this, or just temporarily good luck. 🤔

[chrisgordon]

It's probably just good luck, david9991 ;-) It's not fixed for me in 1.49.1

[chrisgordon]

Not fixed in Version: 1.50.1

[RubenHalman]

I had to downgrade to version 1.39 to be able to keep using VSCode due to this issue too.

[ghidinelli]

Happening to me since last VS Code update on OSX Catalina. I have identified a search query that I can repro with regardless of the setting of search.searchOnType. It's a search for "vcheventname" in a specific folder inside my workspace.

Version: 1.56.2 Commit: 054a9295330880ed74ceaedda236253b4f39a335 Date: 2021-05-12T17:44:30.902Z Electron: 12.0.4 Chrome: 89.0.4389.114 Node.js: 14.16.0 V8: 8.9.255.24-electron.0 OS: Darwin x64 19.6.0

[cfrech-ctx]

Still seeing this issue with VS Code version 1.61 on Mac OS version 11.5.2. Disabling search.searchOnType did not solve it for me. I added a lot of search exclude paths in the hope to prevent it from happening, but so far no luck. I have plenty free RAM and CPU when it happens, so no clear link to some sort of resource starvation.

What I did notice is that for me it more frequently happens at the first search after a longer pause. If I'm lucky and the first search does not crash the system then chances are that I won't hit the issue for a couple hours, even if I'm using search frequently. But this is not always the case and I have seen it crashing my system twice within an hour.

Here my system specs:

Model Name: MacBook Pro Model Identifier: MacBookPro15,3 Processor Name: 6-Core Intel Core i9 Processor Speed: 2.9 GHz Number of Processors: 1 Total Number of Cores: 6 L2 Cache (per Core): 256 KB L3 Cache: 12 MB Hyper-Threading Technology: Enabled Memory: 32 GB System Firmware Version: 1554.140.20.0.0 (iBridge: 18.16.14759.0.1,0)

Enabled extensions:

Extension | Author (truncated) | Version gitlens | eam | 11.6.1 todo-tree | Gru | 0.0.214 python | ms- | 2021.10.1365161279 vscode-pylance | ms- | 2021.10.2 jupyter | ms- | 2021.9.1101343141 jupyter-keymap | ms- | 1.0.0 jupyter-renderers | ms- | 1.0.3 autodocstring | njp | 0.5.4

[risfehani]

VS code 1.62.3 on MacBook pro 2018 running Catalina 10.15.7 .. search crashes the system almost every time.. This has been an issue for as long as I have been using VScode on MacBook pro .. This is a super critical issue since as when dealing with large number of files and many thousands lines of code one can't rely on the VS search but has to use the OS find, or use ATOM!

[cfrech-ctx]

For me the issue disappeared after removing some of my repos from the workspace, so it has something to do with the files that are being searched. I am working now for 3 weeks without a crash, while previously VS code crashed multiple times per day. I have yet to figure out what the problematic repo and file content is.

[roblourens]

If you figure out where the problem is, and can share that folder/file with me, I'd really like to see it.

[shenzhuxi]

Just let you know that searching can also crash Windows 10.

[Louis-udm]

I got the same issue for vscode 1.64.2 in MacBook pro 2018.

[cfrech-ctx]

@roblourens, unfortunately I can no longer reproduce the problem, so I cannot locate the problematic file content. I have not seen a crash for weeks now despite working with repos that were always problematic for me. Not sure what changed.

These are my current specs:

VSCode Version: 1.65.1 (Universal) Commit: 8908a9ca0f221f36507231afb39d2d8d1e182702 Date: 2022-03-08T02:20:11.670Z (1 wk ago) Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0

[Louis-udm]

I updated to 1.65.2 and the issue still there, but I found when I open less 5 projects(folds) in the workspace, the search-in-files works well!

[roblourens]

I've never reproduced this and don't know what the issue is. Is anybody still seeing it?

when I open less 5 projects(folds) in the workspace, the search-in-files works well!

It may be an issue with the number of simultaneous ripgrep processes, but I haven't seen an issue.

[VSCodeTriageBot]

We closed this issue because we are unable to reproduce the problem with the steps you describe. Chances are we've already fixed your problem in a recent version of VS Code. If not, please ask us to reopen the issue and provide us with more detail. Our issue reporting guidelines might help you with that.

Happy Coding!