Closed draeger-charles-wilson closed 7 years ago
It should only create a new one if the old one is still in use. Is the extension leaving behind the -shm and -wal files repeatedly for you?
Did you set the browse.databaseFilename property in c_cpp_properties.json?
Yes the -shm and -wal files are remaining as seen above.
I do include the property.
"databaseFilename": "${workspaceRoot}/.vscode/browse.vc.db"
ok, so it looks like the extension is not shutting down properly if it's leaving all those files behind. Can you share any more details about your config (e.g. settings.json, c_cpp_properties.json, and the repo if it's open source)?
The code is unavailable for viewing. You can assume a normally distributed tree of 33k files over 2k folders totaling 15GB of code.
c_cpp_properties.json:
{
"configurations": [
{
"name": "ARM",
"intelliSenseMode": "clang-x64",
"includePath": [
"C:/RVDS2_2/RVCT/Data/2.2/349/include/windows",
>>> generic heap of project include paths were here <<<
],
"browse": {
"path": [
"C:/RVDS2_2/RVCT/Data/2.2/349/include/windows",
>>> generic heap of project include paths were here (same as above) <<<
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": "${workspaceRoot}/.vscode/browse.vc.db"
},
"defines": [
"c_plusplus",
"_BOOL",
"_WCHAR_T",
"__APCS_ADSABI",
"__APCS_FPIC",
"__APCS_INTERWORK",
"__APCS_ROPI",
"__APCS_RWPI",
"__APCS_SWST",
"__ARMCC_VERSION=220503",
"__arm__arm__",
"__ARRAY_OPERATORS",
"__BASE_FILE__",
"__BIG_ENDIAN",
"__CC_ARM",
"__cplusplus",
"__EDG_IMPLICIT_USING_STD",
"__EDG_VERSION__",
"__EDG__",
"__EXCEPTIONS",
"__FEATURE_SIGNED_CHAR",
"__FP_FAST",
"__FP_FENV_EXCEPTIONS",
"__FP_FENV_ROUNDING",
"__FP_IEEE",
"__FP_INEXACT_EXCEPTION",
"__GNUC_MINOR__=0",
"__GNUC__=3",
"__sizeof_int=4",
"__sizeof_long=4",
"__sizeof_ptr=4",
"__STDC_VERSION__",
"__VERSION__=\"EDG gcc 3.0 mode\"",
>>> bucket-load of project defines were here <<<
}
],
"version": 3
}
user settings:
{
// The proxy setting to use. If not set will be taken from the http_proxy and https_proxy environment variables
"http.proxy": ">>>proxy here<<<",
// enable C/C++ intellisense
"C_Cpp.intelliSenseEngine": "Default",
"C_Cpp.intelliSenseEngineFallback": "Enabled",
"workbench.iconTheme": "material-icon-theme",
// disable task auto-detect
"typescript.tsc.autoDetect": "off",
"grunt.autoDetect": "off",
"jake.autoDetect": "off",
"gulp.autoDetect": "off",
"npm.autoDetect": "off",
"workbench.colorTheme": "Monokai"
// environment variables
}
workspace settings:
{
"files.associations": {
}
}
Our guess is that our process is crashing before it can close the database. After closing VS Code, are you able to delete the database files or is it being used by a dangling process? Also, if you delete the extra "-shm" and "-wal" files and not the .db file, and restart VS Code, does the database get reset to size 0? That would mean the database isn't getting shutdown cleanly. We'll try to fix this via attempting to open the database instead of looking for the extra files.
I'll try both possibilities.
From a closed Code state, I removed the old databases and renamed the newest to have no number. No aux files at this point.
I reopened Code, let it sit and exited. The database went from 250MB to 300KB and has a -shm file present (32KB).
I again opened Code. a browse.vc.2.db with -shm and -wal aux files was created. The original db files are still present.
It looks like the extension is not shutting down cleanly for you. This would imply that even without the change to increment the file names, the extension would be reparsing your whole workspace every time you launch VS Code. @sean-mcmanus any ideas why it's not shutting down cleanly?
Does it say that the database safety check failed when the loggingLevel is turned to Information? I'm not aware of any known issue that could cause shutdown to fail, other than a crash.
Actually, if a long intellisense operation is occurring (red flame) it can block the main thread, causing the shutdown to not be able to complete in 5 seconds (resetting the database).
Where is the loggingLevel setting documented? (found it C_Cpp.LoggingLevel)
Shouldn't this type of database activity gate a normal exit in the same way an unwritten modified file does?
Confirming that if you have Code open with intellisense quiescent, if you view any file, Intellisense's red flame of updatitude appears. If you close Code at this point, the -wal and -shm files will still be present and a new database is generated at next open. Logging level set to informational. Nothing noted on second open.
Thanks for confirming.
VS Code doesn't allow an extension to gate the exit. We get a maximum of 5 seconds.
I believe that VS Code is dropping some of our log messages during initialization. We need to hang onto them until VS Code is ready to receive them. But this issue highlights a problem with IntelliSense that we need to address. The squiggles checking is done on a background thread, but subsequent requests which may be gated by completion of a pending request are blocking the main thread.
For reference, I'm doing exploratory work to determine whether we can use Code for general development. Unfortunately, this is a really high probability event with bad behavior. It happens silently and gives the impression that Intellisense will be running constantly. Makes Code pretty much unusable for large C/C++ projects.
I wouldn't have noticed it myself if I'd not been looking at the tasks.json for another issue.
This should be fixed with version 0.14.3
@bobbrow I still have this issue on vscode version 1.27.2 and c/c++ extension version 0.19.0
@zjuchujinjin That can occur if multiple instances of VS Code are running over the same workspace folder. Is that occurring in your situation?
Using version Version: 1.35.1 (user setup) on windows 10 I am getting this issue. Quickly makes files become a "Large file" to Github. Have added [vscode/.BROWSE.C_CPP.2.DB] to gitignore and solves part of the problem.
OS Windows 7 VSCode 1.18.0 C/C++ extension 0.14.2
I'm working with a C/C++ project which cross-compiles for ARM. It has about 33k files. Intellisense keeps generating additional (new) database files. VSC has not crashed. I have exited it normally on multiple occasions.
What triggers the creation of a new set of database files?
Is there a setting that will force removal of outdated database files in cases where it feels compelled to create new ones?