After enabling the LLDB index cache in production we discovered that some distributed build systems play with the modification times of any .o files that were downloaded from the build cache. This was causing the LLDB index cache to read the wrong cache file for files that didn't have a UUID as all of the modfication times were set to the same value by the build system. When new .o files were downloaded, the only unique identifier was the mod time which were all the same, and we would load an older cache for the updated .o file. So disabling caching of files that have no UUIDs for now until we can create a more solid solution.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/include/lldb/Core/DataFileCache.h | ||
---|---|---|
127 | Do we plan to ship with this design (no caching for module .o file without uuid)? If so, I wonder if we should emit reason information for module not loaded from cache (like signature mismatch/changed vs uuid unavailable)? |
lldb/include/lldb/Core/DataFileCache.h | ||
---|---|---|
127 | I mean emit not-load-from-cache reason in "statistics dump". |
Comment Actions
Added unit tests for CacheSignature that covers:
- making sure encoding fails when we have an invalid CacheSignature
- make sure decoding of older cache files that had a previously valid signature fails when there is no UUID
- fix a bug in the CacheSignature encoding of object modification times
lldb/include/lldb/Core/DataFileCache.h | ||
---|---|---|
130–138 | Nit: I believe this can be simplified as: return m_uuid == rhs.m_uuid && m_mod_time == rhs.m_mod_time && m_obj_mod_time == rhs.m_obj_mod_time; |
Do we plan to ship with this design (no caching for module .o file without uuid)? If so, I wonder if we should emit reason information for module not loaded from cache (like signature mismatch/changed vs uuid unavailable)?