Editing build.conf recursively scans the configured build directory and can crash VS Code with renderer OOM

[moc-sfl]

Describe the bug

When a workspace contains both:

• a BitBake document named build.conf (that the extension recognizes as a Yocto file)
• a build directory of the same name, ie build/

editing build.conf causes the extension to recursively enumerate the entire build/ directory.

extractRecipeName("build.conf") returns build, so getLocalFoldersForRecipeUri() calculates the recipe-local directory as <workspace>/build. The extension then:

1. Calls vscode.workspace.findFiles() with **/*, no exclusion, and no result limit.
2. Calls synchronous find.dirSync() on the same directory.

In a Yocto workspace with millions of file representing hundreds of gigs, this repeatedly made the extension host unresponsive and eventually crashed the renderer after exhausting its 4 GB V8 heap.

The standard "**/build/**" VS Code exclusion does not protect this search because the RelativePattern base is already <workspace>/build; returned paths are relative to that directory.

With embedded-language support enabled, this also generated .py documents and activated the Python extension while the extension host was blocked, resulting in an indefinitely running “Python extension loading” notification.

To Reproduce

1. Create a workspace resembling:

workspace/ 
├── build.conf 
├── build/<a large generated Yocto build tree> 
└── sources/<one or more .bb files>

2. Configure:
   "files.associations": {
   "*.conf": "bitbake"
   },
   "bitbake.pathToBuildFolder": "${workspaceFolder}/build" }
3. Open build.conf.
4. Make any edit to the document.
5. Observe the extension host become unresponsive while the sibling  build/  directory is recursively searched.
6. With a sufficiently large build tree, the VS Code renderer eventually crashes.

A minimal build.conf is sufficient; its contents are not important.

Expected behavior
build.conf should not be treated as a recipe named  build  for recipe-local  SRC_URI  file discovery.
Recipe-local file discovery should never recursively enumerate the configured BitBake build output directory. Searches should also be bounded and cancellable.

I understand that the .conf file association might not be intended, but in practice it has made the extension more convenient to use.

Desktop:
• OS: Pop!_OS 22.04 LTS, kernel 7.0.11-76070011-generic
• VS Code version: 1.128.0 when the renderer crashes occurred
• Extension version: 2.9.0
• Yocto version: 5.0.18
• Architecture: x64

Debug logs
The renderer exits with code 132. Crashpad dumps show that this is V8 deliberately terminating after reaching its heap limit:

Reached heap limit

$handleFileMatch
addMatch
handleFindMatch
$handleFileMatch

The dump contains retained file-search results from paths such as:

<workspace>/build/tmp/work-shared/.../kernel-source/...
<workspace>/build/tmp-k3r5/work-shared/gcc-.../gcc/testsuite/...

The renderer log reports:

CodeWindow: renderer process gone (reason: crashed, code: 132)
Extension host (...) is unresponsive.
UNRESPONSIVE extension host: starting to profile NOW

Relevant installed extensions:

yocto-project.yocto-bitbake@2.9.0
ms-python.python@2026.4.0
ms-python.vscode-pylance@2026.2.1
ms-python.vscode-python-envs@1.36.0

Additional context
The problematic flow appears to be:

•  server/src/server.ts :  documents.onDidChangeContent()  requests  getRecipeLocalFiles  for every changed BitBake document.
•  client/src/documentLinkProvider.ts :  getLocalFoldersForRecipeUri()  maps  build.conf  to the sibling  build/  directory.
•  findFilesAndDirs()  performs an unbounded  workspace.findFiles()  call and a synchronous recursive  find.dirSync() .

Current upstream implementation:

• https://github.com/yoctoproject/vscode-bitbake/blob/staging/server/src/server.ts
• https://github.com/yoctoproject/vscode-bitbake/blob/staging/client/src/documentLinkProvider.ts

Potential fixes:

1. Do not request recipe-local files for non-recipe documents such as  .conf .
2. Reject candidate directories equal to or contained within  bitbake.pathToBuildFolder .
3. Add a reasonable  maxResults  limit to  workspace.findFiles() .
4. Replace  find.dirSync()  with a bounded, asynchronous, cancellable traversal.
5. Ideally perform this discovery lazily when  SRC_URI  completion is actually requested rather than on every document change.

A local patch that skips the configured build folder and caps results stopped the renderer OOM. Setting:

"bitbake.disableEmbeddedLanguagesFiles": true

also prevented the secondary Python-extension loading loop, while leaving core BitBake functionality enabled.

[deribaucourt]

Hello,
Thanks for reporting this issue and the in-depth analysis!

Ideally, we would limit the search to FILESDIR, but to know this variable, we would need a recipe scan, which is way more expensive than the current find() calls. Maybe if someday we have a direct connection with the bitbake database, we could get the result that way.

We should implement the following changes:

1. BitbakeDocumentLinkProvider currently has no unit tests. They should be added before the change to prevent regressions.
2. Filter .conf files before calling getLocalFoldersForRecipeUri. This should be done not in the function, but at the top of the call chain where it makes logical sense.
3. Move getRecipeLocalFiles() call from onDidChangeContent -> getBitBakeCompletionItems. Let's verify if the user experience is not degraded, and the results come up fast enough in the general case. However, the client-side provideDocumentLinks is called by vscode. We can't influence it.
4. Replace dirSync with an async version in findFilesAndDirs. This function is already async. async allows the vscode process to service other rendering requests while it completes that one.
5. Add a timeout on the find functions called in findFilesAndDirs. On .bb/.inc files, it should be very rare to have a $PN or files directory with heaps of data. However, if it is (like a gigantic app local build), then users will also face this issue.