Fix memory overrun possibility during tick samples processing.

Fix memory overrun possibility during tick samples processing.

This really can cause crash described in crbug/51919.

BUG=51919
TEST=NONE

Committed: http://code.google.com/p/v8/source/detail?r=5391

[Søren Thygesen Gjesse, 2010-09-01 12:21:57]

http://codereview.chromium.org/3334001/diff/1/2
File src/cpu-profiler.cc (right):

http://codereview.chromium.org/3334001/diff/1/2#newcode243
src/cpu-profiler.cc:243: TickSampleEventRecord record = *rec;
If I remember correctly the queue is an array of TickSampleEventRecords being
filled by the sample writer. Then how does this copy (struct memcpy) ensure that
the content of record is not a mix of two sample records?

[mnaganov (inactive), 2010-09-01 12:32:56]

On 2010/09/01 12:21:57, Søren Gjesse wrote:
> http://codereview.chromium.org/3334001/diff/1/2
> File src/cpu-profiler.cc (right):
> 
> http://codereview.chromium.org/3334001/diff/1/2#newcode243
> src/cpu-profiler.cc:243: TickSampleEventRecord record = *rec;
> If I remember correctly the queue is an array of TickSampleEventRecords being
> filled by the sample writer. Then how does this copy (struct memcpy) ensure
that
> the content of record is not a mix of two sample records?

It doesn't, but it's not that scary -- as a result, we will just have an
inconsistent stack trace -- a noise. The purpose of copying is make sure that
RecordTickSample doesn't work with a record being changed under its feet. E.g.
RTS allocates a buffer using frames_count, then it fills it, again using
frames_count, so if frames_count changes on the fly, memory overrun happens.

[Søren Thygesen Gjesse, 2010-09-01 12:55:39]

LGTM, but maybe we could do more to ensure consistency.

[mnaganov (inactive), 2010-09-01 13:04:14]

On 2010/09/01 12:55:39, Søren Gjesse wrote:
> LGTM, but maybe we could do more to ensure consistency.

Yes, we can. The current solution is simple enough to be painlessly patched into
M6 and M7, and the only drawback is a possibility of having an inconsistent
sample (this doesn't incur crashing, of course).

I will think on further improvements of consistency!