summaryrefslogtreecommitdiffstats
path: root/third_party/harfbuzz-ng
diff options
context:
space:
mode:
authorjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-03-16 15:31:39 +0000
committerjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-03-16 15:31:39 +0000
commit3b0be97b587797d06198472242f814980872b1b0 (patch)
tree63455b1280c95009e9207f0c076d5b95673fc827 /third_party/harfbuzz-ng
parent71de819b6409c3fc9886c0d07e2e6216d1a52703 (diff)
downloadchromium_src-3b0be97b587797d06198472242f814980872b1b0.zip
chromium_src-3b0be97b587797d06198472242f814980872b1b0.tar.gz
chromium_src-3b0be97b587797d06198472242f814980872b1b0.tar.bz2
Add redundancy to detect double frees in TCMalloc
I don't think I want to ship this to dev or stable, but I think it may be valuable to try on our canary builds. Added a single byte or word (tranparently) to all allocations, and wrote a unique value into that location after each allocation. When free() is called, we validate the flag, and then mark the block as not being allocated. Any time a block fails to validate, we crash, as this means the object either overran its allocated region (or suffered memory corruption), or else (more likely) a double free took place. We have two distinct crash stacks for the two distinct validation problems (corrupt vs double free). ALthough I haven't been able to demonstrate a problem on the bots, I'm pretty psyched to try to find something in the field with this change. The perf loss is very low, and I think that the likely cause for TCMalloc cross-linked-list corruption (double frees) will be detected (I can hope!) R=mbelshe BUG=75921 Review URL: http://codereview.chromium.org/6683029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78369 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'third_party/harfbuzz-ng')
0 files changed, 0 insertions, 0 deletions