6dd88144d5
If SkRefCnt_SafeAssign is erroneously invoked simultaneously by two threads on the same destination, a likely outcome is that the reference count of an object other than the replaced dst will be decremented. This results in an extra reference count decrement, which usually means that the final reference count decrement will be applied to a random location in an object that has already been reallocated. This is exceedingly hard to debug. We add a hack to detect such data races with sufficiently high probability, so that such a data race bug should sometimes actually generate bug reports that lend themselves to diagnosis. We detect changes within a relatively larger range that normally includes several (typically slow) memory fences. Not all such changes would provoke a crash. Even if we decrement the wrong reference count, there's a chance we would decrement a dead location. Thus, to avoid potentially adding instability, we currently only log. This change tries to minimize additional runtime overhead. The macro is only expanded a few dozen times, so we do not worry too much about code size. Bug: b/31227650 Change-Id: Ia40c9ed2c4d0fa578ea682fbec4b71a2ef22a5d1 Reviewed-on: https://skia-review.googlesource.com/9994 Commit-Queue: Derek Sollenberger <djsollen@google.com> Reviewed-by: Mike Klein <mtklein@chromium.org> |
||
|---|---|---|
| .. | ||
| android | ||
| c | ||
| codec | ||
| config | ||
| core | ||
| effects | ||
| gpu | ||
| pathops | ||
| ports | ||
| private | ||
| svg | ||
| utils | ||
| views | ||