Lookup and subsequent insert was done using uninitialized
FileSpec object, which caused the cache to be a no-op.
Bug: llvm.org/PR45310
Depends on D76804.
Differential D76805
Fix SourceManager::SourceFileCache insertion emrekultursay on Mar 25 2020, 2:55 PM. Authored by
Details Lookup and subsequent insert was done using uninitialized Bug: llvm.org/PR45310 Depends on D76804.
Diff Detail
Event TimelineComment Actions IIUC, you should be able to test the actual effect you are trying to achieve by having a large source file, running "source list" to get it into the File Manager, then try to open the source file for writing in a process in a subshell that won't have the same mmap. That should fail without the patch (or with the setting turned to cache-on) and succeed with it. Comment Actions Looks good. I'm just picking some nits in the test. I'm assuming that @jingham's comment refers to the other patch (and it more-or-less matches what I wrote there already). Does this actually depend on the other patch? It looks like an independent fix we could commit separately.
Comment Actions
This bug seems to have existed forever. Fixing it means we will have source file cache enabled for the first time. If it causes any unforeseen issues, I'd like users to have the ability to disable the cache, which is why I made this change depend on the other change. Comment Actions Ok, that makes kind of sense, though I am left wondering if we really need this feature, given that we have survived so long without noticing it is missing... Am I understanding it correctly that without this patch, we would only cache the most recently accessed file (via m_last_file_sp member), and would always reload when switching to a new file? Comment Actions Yes, without this patch, only the most recently accessed file is cached inside that member, and switching to a new file replaces that entry. I guess this was designed for optimizing the case where the user hits "next line" while staying in the same file. Yet, if a breakpoint on a different file is hit during that "next line" command, we trigger a reload (twice). This patch will increase memory usage, as mapped source files will stay in the cache, and thus, never be unmapped. The increase will be and proportional to the size of source files loaded by LLDB on-demand. |
Woops :)