• Alex Kodat's avatar
    [cpu-profiler] Don't sample wrong thread's stack in profiler · bf9e8d2c
    Alex Kodat authored
    76217f57 fixed the profiler so it would only sample a thread if
    it had the Isolate lock. Unfortunately, this fix missed a timing
    window where a thread might have the Isolate lock but might not
    have restored the thread-specific data such as thread_local_top_
    for the locked thread yet, so the sampler might end up using data
    from a different thread.
    
    This doesn't cause any seg faults or the like because the thread
    we *meant* to sample has the Isolate lock so the thread we're
    accidentally sampling can't mess with any Isolate data but we can
    still get incorrect sample data which can be especially obvious if
    the accidentally sampled thread is inside code that would never
    run on the thread we meant to sample.
    
    Fortunately, we can tell when all thread-specific data has been
    restored to the Isolate because thread_state_ in the
    PerIsolateThreadData for a thread is set to a non-null value
    until everything has been restored, at which point it gets set
    to null. So the fix adds a check after the test for the Isolate
    lock to check if thread_state_ is null for the thread we mean to
    sample. If so, we know all the data in the Isolate is good to go
    for sampling.
    
    Bug: v8:11316
    Change-Id: I02d6361d8cbd6ec809ad8fb7ef07f5e9c94c7d1e
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2628133Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
    Commit-Queue: Peter Marshall <petermarshall@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#72112}
    bf9e8d2c
test-cpu-profiler.cc 144 KB