Task: run V8 tests under Dr. Memory

[derekbruening]

From [email protected] on July 27, 2011 11:58:54

I see plenty of uninit reports from V8 under Dr. Memory.
e.g. http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20%28DrMemory%29/builds/4643/steps/memory%20test%3A%20unit_1/logs/stdio -> 238/257 of UNINIT reports are from V8.

It could be Dr. Memory missing something or V8 messing something up.

I'm going to suppress all uninits in V8 in Chromium until V8 runs OK w/o Chromium.

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

[derekbruening]

From [email protected] on July 27, 2011 09:01:45

xref https://code.google.com/p/dynamorio/issues/detail?id=242

[derekbruening]

From [email protected] on March 21, 2012 07:19:53

I spent a bit investigating this, these are all bit-level fps. V8 uses lots of bitfields. The first two reports are from:

0 v8::internal::GlobalHandles::Node::next_free [f:\src\src\v8\src\global-handles.cc:176]

This reads state_, which is declared as:
// Need one more bit for MSVC as it treats enums as signed.
State state_ : 4;

bool independent_ : 1;
bool in_new_space_list_ : 1;

independent_ and the rest are uninit.

The next report is from:

0 unibrow::Predicateunibrow::WhiteSpace,128::get [f:\src\src\v8\src\unicode-inl.h:37]

which is reading code_point_:
if (entry.code_point_ == code_point) return entry.value_;
which is declared as:
uchar code_point_ : 21;
bool value_ : 1;

So more bit-level. I haven't investigated further, but I think this is going to be the lion's share of the reports.

Right now in issue #792 we're running out of memory from generating thousands of symbolized stack traces and suppressing them.

I don't think there's a good way to resolve this issue other than finally implementing issue #113 . Let's make that an OKR for the next quarter.

Owner: [email protected]
Labels: FalsePos-BitLevel Bug-FalsePositive