{{ message }}
Repository navigation
Browse database relocated to /var/tmp despite settings; quickly consumes all available space under / #14795
Description
Environment
- OS and Version: macOS 26.5.2 (VSCode Editor)
- VS Code Version: 1.138.0
- C/C++ Extension Version: 1.34.4
- If using SSH remote, specify OS of remote machine: Rocky Linux 8.9
Bug Summary and Steps to Reproduce
After updating the C/C++ IntelliSense plugin and VSCode earlier today, I quickly discovered my SSH remote had run out of disk space on /. On investigating, I found a 41GB .browse.VC.db file under /var/tmp/.vscode-cpptools-XXXXXX.
If I delete this file and kill remote cpptools-srv2 instances, the language server restarts, immediately recreates .browse.VC.db, and begins filling the file.
I do see a 70+GB file at the location specified by c_cpp_properties.json (see below), but it appears this configuration setting is no longer being honored. Nor is the path specified by C_Cpp.default.browse.databaseFilename.
This was working until the recent upgrade.
Configuration and Logs
-------- Diagnostics - 9/23/2026, 1:45:49 AM
Version: 1.34.4
Current Configuration:
{
"name": "Linux",
"includePath": [
"<REDACTED>"
],
"defines": [
"_DEBUG",
"UNICODE",
"_UNICODE",
"NV_LINUX"
],
"compilerPath": "/usr/bin/gcc",
"cStandard": "c11",
"cppStandard": "c++17",
"intelliSenseMode": "linux-gcc-x64",
"browse": {
"path": [
"<REDACTED>"
],
"limitSymbolsToIncludedHeaders": false,
"databaseFilename": "${workspaceFolder}/.vscode/browse.vc.db"
},
"compilerPathIsExplicit": true,
"cStandardIsExplicit": true,
"cppStandardIsExplicit": true,
"intelliSenseModeIsExplicit": true,
"recursiveIncludesPriorityIsExplicit": false,
"recursiveIncludesOrderIsExplicit": false,
"compilerPathInCppPropertiesJson": "/usr/bin/gcc",
"mergeConfigurations": false,
"recursiveIncludes": {}
}
Modified Settings:
{
"C_Cpp.errorSquiggles": "enabled",
"C_Cpp.default.compilerPath": "/usr/bin/gcc",
"C_Cpp.default.cStandard": "c11",
"C_Cpp.default.cppStandard": "c++17",
"C_Cpp.default.browse.databaseFilename": "/data/vscode-cpptools/${workspaceFolderBasename}/browse.vc.db",
"C_Cpp.intelliSenseCachePath": "/data/vscode-cpptools"
}
Additional Tracked Settings:
{
"editorTabSize": 4,
"editorInsertSpaces": true,
"editorAutoClosingBrackets": "languageDefined",
"filesEncoding": "utf8",
"filesAssociations": {
"*.c": "c",
"*.cpp": "cpp",
"*.h": "c",
"*.hpp": "cpp"
},
"filesExclude": {
"**/.git": true,
"**/.svn": true,
"**/.hg": true,
"**/.DS_Store": true,
"**/Thumbs.db": true
},
"filesAutoSaveAfterDelay": false,
"editorInlayHintsEnabled": true,
"editorParameterHintsEnabled": true,
"searchExclude": {
"**/node_modules": true,
"**/bower_components": true,
"**/*.code-search": true
},
"workbenchSettingsEditor": "ui"
}
cpptools version (native): 1.34.3.0
Current database path: /var/tmp/.vscode-cpptools-102571/browse-database/{16150885415521154784}/.browse.VC.db
No active translation units.Other Extensions
No response
Additional context
No response
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
[-]Browse database relocated to /var/tmp despite settings; quickly consumes all available space under `/`[/-][+]Browse database relocated to `/var/tmp` despite settings; quickly consumes all available space under `/`[/+]sean-mcmanus commentedon Sep 23, 2026
2yy45tr2r9-cpu To clarify, is the issue just with the database location and not its size very large size? i.e. is the large size expected/pre-existing?
Also, can you set your C_Cpp.loggingLevel to "Information" or "Debug" and look for any "filesystem, which cannot back WAL shared memory" logging in the C/C++ output pane? We changed it to move to the /var/tmp in that case.
Colengms commentedon Sep 25, 2026
Hi 2yy45tr2r9-cpu . There are two recent 'fixes' that might be involved here.
Could you enable debug logging (`"C_Cpp.loggingLevel": "Debug"), and check if there is logging specifically referring to either of these scenarios in the Output for C/C++? (Or any logging related to the database file failing to open at the desired location.)
I suspect you may be encountering the former issue, as that might explain why it does not use your configured path. If so, could you provide the file system information for that path, using? :
findmnt -T "<path>" -no FSTYPE,OPTIONSjusherma commentedon Oct 1, 2026
We are seeing this issue too, and in our case, automated cleanup of /tmp is removing these large files, but cpptools is holding stale file descriptors on them indefinitely, so the disk space is not being reclaimed. We have had to forcibly stop cpptools processes to reclaim the disk space, at which point it restarts and continues eating disk again
Colengms commentedon Oct 1, 2026
Hi Justin Sherman (@jusherma) . Could you provide additional information that might help us determine why only certain people are seeing this behavior?
Could you enable debug logging (
"C_Cpp.loggingLevel": "Debug"), and check for anything in the Output for C/C++ related to errors opening the DB or reasons for redirecting it to another location?Could you provide the file system information for the path of your project (or where it should be storing the database) using :
findmnt -T "<path>" -no FSTYPE,OPTIONSjusherma commentedon Oct 2, 2026
Hi Colen Garoutte-Carson (@Colengms), yes, let me work with a developer seeing this issue. I was unable to reproduce it myself, but a few teammates are seeing it consistently. In the interim, here's an example of what we see from lsof when the issue happens. Note that cpptools is holding a bunch of stale file descriptors for files that have already been deleted. This means the disk space is used with no way of reclaiming it besides killing the cpptools process itself.
A couple things specific to our environment:
jusherma commentedon Oct 2, 2026
Colen Garoutte-Carson (@Colengms) After killing the above process, the user's vscode client respawned a fresh cpptools process, which started flooding /tmp again. I see that in this instance it's the write-ahead log file that's bloated in size. The actual db file is only 8K. At this point, /tmp cleanup automation has not kicked in yet
and it's growing quite quickly
jusherma commentedon Oct 3, 2026
Colen Garoutte-Carson (@Colengms) We're having trouble reproducing this on demand. If we can, I'll send along the requested high-verbosity logs. To answer your other question regarding file system type:
/var/tmp is part of /
Both are local ext4 filesystems, no NFS. (I know that can cause issues with sqlite WAL)
Colengms commentedon Oct 5, 2026
Could someone who is repro'ing this issue help us out by providing the following information?
findmnt -T <path> -no FSTYPE,OPTIONS- run against the intended path (not the fallback path).How the default path is chosen:
Copilot suggests providing the output of:
It would also be possible to explicitly set a database path, either in
c_cpp_properties.json:Or a setting:
You might try setting the path explicitly, as a possible work-around. The database is not expected to be in
/var/tmpunless there had been an issue creating it in the intended target location.What platforms (distros of Linux?) are people experiencing this issue with? Is it limited to
Rocky Linux 8.9? As not everyone is experiencing this issue, details of the reproducing environments may be helpful.Also, can anyone isolate the specific version of the extension the repro started with?