commit | 2e85b51a0233292853e0288c7df2fb639acda732 | [log] [tgz] |
---|---|---|
author | Luc Nguyen <lucnguyen@google.com> | Tue Feb 06 03:32:12 2024 |
committer | Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Feb 06 03:32:12 2024 |
tree | f3a4dc5aba589ea7abfbb806d9c9832ca2557db5 | |
parent | 88e799a262ebd02a231c8f0541425079b60aff40 [diff] |
Tentative fix for objects being allocated on top of each other There are indications that somehow, objects in persistent memory are being allocated on top of each other. For example, histogram objects in persistent memory have a pointer to their samples vector. Crash reports show that sometimes, the pointers point to 0xC8799269. This is typically not a valid memory location. Rather, it's a magic number in persistent memory code when allocating a new object. So, somehow, a new object was allocated on top of the histogram object, and 0xC8799269 was written to where an histogram object stores a pointer to its samples. The persistent memory allocator has a "freeptr", which is what keeps track of where to allocate a new object. Assuming the aforementioned issue isn't caused by some generic memory corruption due to hardware (which is unlikely due to the sheer number of crash reports for this problem), then somehow freeptr must be getting decreased in value (it is supposed to be strictly increasing). This would result in the next new object being allocated on top of where an object was already allocated. There are only two places in the code base where we update "freeptr": 1. When allocating a new object. 2. When initializing the persistent memory. The code surrounding case 1 is tricky, but I've read it a million times and can't find any race conditions. I've also read the assembly code to see if a compiler optimization might be creating a race condition, but couldn't find anything there either. As for case 2, it should theoretically not be possible, as it would require two processes to be working with the same persistent file. This shouldn't be possible because we protect against this using timestamps and PIDs to generate unique filenames. However, assuming that there is somehow a way for two processes to be working with the same file, then there is a very small window where "freeptr" would get decremented/"rewinded". This CL tentatively fixes this to see if this has an effect. In my opinion, this is unlikely to be the cause since the race window is so small, but this will let us rule it out with certainty. Bug: 1432981 Change-Id: I3caf61b4cba0a58b099e24a7f6ca61b2d7b7f794 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5269743 Commit-Queue: Alexei Svitkine <asvitkine@chromium.org> Reviewed-by: Alexei Svitkine <asvitkine@chromium.org> Cr-Commit-Position: refs/heads/main@{#1256589}
Chromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
To check out the source code locally, don't use git clone
! Instead, follow the instructions on how to get the code.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure.
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.
If you found a bug, please file it at https://crbug.com/new.