Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(282)

Issue 1892533003: Catch illegal hash table modifications when they happen.

Created:
4 years, 8 months ago by sof
Modified:
4 years, 8 months ago
Reviewers:
CC:
chromium-reviews, blink-reviews, blink-reviews-wtf_chromium.org, Mikhail
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

Catch illegal hash table modifications when they happen. Not for landing, this approach won't work out -- iterator stack lifetimes aren't accurate wrt the period we want hash tables not to be modifiable. Iterator lifetime is accurate for something like for (auto it : m_observers) { ..cannot modify m_observers here.. } but not for auto it = m_observers.find(o); if (it != end()) return; m_observers.add(o);

Patch Set 1 #

Patch Set 2 : introduce mod-forbidden scoping #

Patch Set 3 : add reqd copy ctor #

Unified diffs Side-by-side diffs Delta from patch set Stats (+120 lines, -114 lines) Patch
M third_party/WebKit/Source/wtf/HashTable.h View 1 2 27 chunks +97 lines, -100 lines 0 comments Download
M third_party/WebKit/Source/wtf/LinkedHashSet.h View 1 2 5 chunks +23 lines, -14 lines 0 comments Download

Messages

Total messages: 3 (1 generated)
haraken
Thanks for digging into this. > auto it = m_observers.find(o); > if (it != end()) ...
4 years, 8 months ago (2016-04-18 00:05:29 UTC) #2
sof
4 years, 8 months ago (2016-04-18 07:29:08 UTC) #3
On 2016/04/18 00:05:29, haraken wrote:
> Thanks for digging into this.
> 
> >  auto it = m_observers.find(o);
> >  if (it != end())
> >      return;
> >  m_observers.add(o);
> 
> Another verification idea would be to invalidate the iterator when there is
any
> modification on the hash table, so that a subsequent access on the iterator
will
> just crash?

checkModifications() is called on advancing the iterator and access (get()), so
the mechanism is in place.

Using release asserts for these will require growing the size of HashTable (and
iterators) to hold a modification counter; that is the trade-off here.

Powered by Google App Engine
This is Rietveld 408576698