From bruen...@google.com on May 02, 2011 10:41:22

originally it looked like we had a 100x slowdown vs prior runs:

prior run:
[----------] 1 test from FtpDirectoryListingBufferTest
[ RUN ] FtpDirectoryListingBufferTest.Parse
[ OK ] FtpDirectoryListingBufferTest.Parse (4261 ms)
[----------] 1 test from FtpDirectoryListingBufferTest (4261 ms total)

w/ newer chromium build and newer drmem (has ioctl checking):
[----------] 1 test from FtpDirectoryListingBufferTest
[ RUN ] FtpDirectoryListingBufferTest.Parse
[ OK ] FtpDirectoryListingBufferTest.Parse (390999 ms)
[----------] 1 test from FtpDirectoryListingBufferTest (391000 ms total)

but turns out they changed the test and made it longer, so re-analyzing vs
native, and focusing on just this test (so #s may be slightly different
than when running as part of full set of tests):

new chromium build, native run:
[ RUN ] FtpDirectoryListingBufferTest.Parse
[ OK ] FtpDirectoryListingBufferTest.Parse (10735 ms)
and using drmem release build instead of debug:
[ RUN ] FtpDirectoryListingBufferTest.Parse
[ OK ] FtpDirectoryListingBufferTest.Parse (337538 ms)

=> 31x slowdown, so not completely ridiculous, but may well be worth looking at

also, this Parse test aborts w/ assert when run under drmem w/ extra logging:

w/ drmem w/ SYSCALL_VERBOSE=1 the Parse test exited net_unittests w/ an
assert -- I didn't record the callstack though.
total runtime to that point was something like 4.5 mins.

maybe the extra verbosity hit some internal timeout.

note that tsan now times out and excludes this test
( http://crbug.com/79022 ) w/ the recent (April 11, 2011) changes to the
test:

Date: Mon Apr 11 11:52:17 2011 +0000
Disables FtpDirectoryListingBufferTest.Parse on our TSAN bots.
It seems r81081 < http://crrev.com/81081 > added more test cases to the FtpDirectoryListingBufferTest.P

Original issue: http://code.google.com/p/drmemory/issues/detail?id=370