DynamoRIO / DynamoRIO/drmemory
CookieMonsterTest.TestLastAccess fails under Dr. Memory
- Dominant language
- C
- Stars
- 2.7k
- Forks
- 290
- PR merge metrics
- No merged PRs in 30d
Description
_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on May 02, 2011 13:10:47_
my ioctl tree on full net_unittests run:
[ RUN ] CookieMonsterTest.TestLastAccess
.\base\cookie_monster_unittest.cc(1025): error: Value of: last_access_date == GetFirstCookieAccessDate(cm)
Actual: false
Expected: true
[ FAILED ] CookieMonsterTest.TestLastAccess (2246 ms)
passed a month ago, and passed w/ r273 just now:
[ RUN ] CookieMonsterTest.TestLastAccess
[ OK ] CookieMonsterTest.TestLastAccess (395 ms)
tsan excludes:
# These tests fail due to unknown reasons
# TODO(timurrrr): investigate
CookieMonsterTest.TestLastAccess
but w/ r273 running just that test it fails: both debug and release.
w/ plain DR: release build succeeds, but debug DR fails!
running CookieMonsterTest._: r273 release succeeds: and the test takes just 335ms.
run by itself it takes 1200ms or so -- or is the rest of that the error
reporting?
indeed, release build of ioctl tree succeeds on CookieMonsterTest._.
so does debug: so prior failure on full net_unittests run was a fluke?
just flaky test that's really sensitive to timing I guess
looking at the sources (~/chromium/src/net/base/cookie_monster_unittest.cc)
it reads cookie again immediately and expects the access date to not have
changed, and then reads again after a short wait after which it should
have changed: so if tool slows it down enough then test will fail.
static const int kLastAccessThresholdMilliseconds = 200;
so it waits 220ms.
definitely timing-sensitive. filing this to remind us in case it fails in future. not going to add to exclude list yet since succeeds in release build in full test suite.
_Original issue: http://code.google.com/p/drmemory/issues/detail?id=372_
Contributor guide
Assessment
This issue has not been assessed yet.