• joth@chromium.org's avatar
    Revert 107939 - Pile of nits for tracked object enablement · a0645703
    joth@chromium.org authored
    [Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
    with supressions for induced (and planned) leaks) 
    PLUS
    Removed one line of defensive coding where I set(NULL)
    the TLS slote at thread teardown. We're seeing
    strange failures on the base unittests, and they
    may be related to this.
    ]
    
    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.
    
    tbr=rtenneti
    bug=102327
    Review URL: http://codereview.chromium.org/8425010
    
    TBR=jar@chromium.org
    Review URL: http://codereview.chromium.org/8430003
    
    git-svn-id: svn://svn.chromium.org/chrome/trunk/src@107960 0039d316-1c4b-4281-b951-d872f2087c98
    a0645703
suppressions.txt 38.9 KB