GitLab

[Being extra conservative an leaking tracking data got
the base_unittest heap_checkers too excited. I need 
a supresion to match what we already have in the 
browser runs to calm them... so I'll revert for now.]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task.  This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking.  These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled.  This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

r=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8414050

TBR=jar@chromium.org
Review URL: http://codereview.chromium.org/8414051

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107922 0039d316-1c4b-4281-b951-d872f2087c98