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}
1 file changed
tree: f3a4dc5aba589ea7abfbb806d9c9832ca2557db5
  1. android_webview/
  2. apps/
  3. ash/
  4. base/
  5. build/
  6. build_overrides/
  7. buildtools/
  8. cc/
  9. chrome/
  10. chromecast/
  11. chromeos/
  12. codelabs/
  13. components/
  14. content/
  15. courgette/
  16. crypto/
  17. dbus/
  18. device/
  19. docs/
  20. extensions/
  21. fuchsia_web/
  22. gin/
  23. google_apis/
  24. google_update/
  25. gpu/
  26. headless/
  27. infra/
  28. ios/
  29. ipc/
  30. media/
  31. mojo/
  32. native_client_sdk/
  33. net/
  34. pdf/
  35. ppapi/
  36. printing/
  37. remoting/
  38. rlz/
  39. sandbox/
  40. services/
  41. skia/
  42. sql/
  43. storage/
  44. styleguide/
  45. testing/
  46. third_party/
  47. tools/
  48. ui/
  49. url/
  50. webkit/
  51. .clang-format
  52. .clang-tidy
  53. .clangd
  54. .eslintrc.js
  55. .git-blame-ignore-revs
  56. .gitallowed
  57. .gitattributes
  58. .gitignore
  59. .gitmodules
  60. .gn
  61. .mailmap
  62. .rustfmt.toml
  63. .vpython3
  64. .yapfignore
  65. ATL_OWNERS
  66. AUTHORS
  67. BUILD.gn
  68. CODE_OF_CONDUCT.md
  69. codereview.settings
  70. DEPS
  71. DIR_METADATA
  72. LICENSE
  73. LICENSE.chromium_os
  74. OWNERS
  75. PRESUBMIT.py
  76. PRESUBMIT_test.py
  77. PRESUBMIT_test_mocks.py
  78. README.md
  79. WATCHLISTS
README.md

Logo Chromium

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.