uninit in v8::internal::Isolate::DoThrow that requires bitlevel

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on April 22, 2014 14:42:39_

This is reported by Dr. Memory when running net_unittests
--gtest_filter=ProxyResolverV8TracingTest.JavascriptError (currently there
are some default Chromium suppressions hiding this, so you have to run w/o
those suppressions to see it):

Error `#1`: UNINITIALIZED READ: reading 0x0411cd7d-0x0411cd7e 1 byte(s)
#0 v8.dll!v8::internal::Isolate::DoThrow [e:\derek\chromium\src\v8\src\isolate.cc:1088]
#1 v8.dll!v8::internal::Isolate::Throw [e:\derek\chromium\src\v8\src\isolate.cc:906]
#2 v8.dll!v8::internal::IC::TypeError [e:\derek\chromium\src\v8\src\ic.cc:385]
#3 v8.dll!v8::internal::LoadIC::Load [e:\derek\chromium\src\v8\src\ic.cc:580]
#4 v8.dll!v8::internal::__RT_impl_LoadIC_Miss [e:\derek\chromium\src\v8\src\ic.cc:1809]
#5 v8.dll!v8::internal::Invoke [e:\derek\chromium\src\v8\src\execution.cc:94]
#6 v8.dll!v8::internal::Execution::Call [e:\derek\chromium\src\v8\src\execution.cc:151]
#7 v8.dll!v8::Function::Call [e:\derek\chromium\src\v8\src\api.cc:3993]
#8 net_with_v8.dll!net::ProxyResolverV8::Context::ResolveProxy [e:\derek\chromium\src\net\proxy\proxy_resolver_v8.cc:388]
#9 net_with_v8.dll!net::ProxyResolverV8::GetProxyForURL [e:\derek\chromium\src\net\proxy\proxy_resolver_v8.cc:731]
#10 net_with_v8.dll!net::ProxyResolverV8Tracing::Job::ExecuteProxyResolver [e:\derek\chromium\src\net\proxy\proxy_resolver_v8_tracing.cc:690]
#11 net_with_v8.dll!net::ProxyResolverV8Tracing::Job::ExecuteNonBlocking [e:\derek\chromium\src\net\proxy\proxy_resolver_v8_tracing.cc:646]
#12 net_with_v8.dll!base::internal::Invoker<>::Run [e:\derek\chromium\src\base\bind_internal.h:1169]
#13 base.dll!base::MessageLoop::RunTask [e:\derek\chromium\src\base\message_loop\message_loop.cc:452]
#14 base.dll!base::MessageLoop::DeferOrRunPendingTask [e:\derek\chromium\src\base\message_loop\message_loop.cc:464]
#15 base.dll!base::MessageLoop::DoWork [e:\derek\chromium\src\base\message_loop\message_loop.cc:578]
#16 base.dll!base::MessagePumpDefault::Run [e:\derek\chromium\src\base\message_loop\message_pump_default.cc:32]
#17 base.dll!base::MessageLoop::RunHandler [e:\derek\chromium\src\base\message_loop\message_loop.cc:402]
#18 base.dll!base::Thread::Run [e:\derek\chromium\src\base\threading\thread.cc:172]
#19 base.dll!base::Thread::ThreadMain [e:\derek\chromium\src\base\threading\thread.cc:225]
#20 base.dll!base::`anonymous namespace'::ThreadFunc [e:\derek\chromium\src\base\threading\platform_thread_win.cc:78]
#21 KERNEL32.dll!BaseThreadInitThunk +0x11 (0x74df338a )
Note: @0:00:15.990 in thread 3720
Note: instruction: cmp 0x00001b15(%edi) $0x00

Error `#1`: UNINITIALIZED READ: reading 0x0411cd7d-0x0411cd7e 1 byte(s)
#0 v8.dll!v8::internal::Isolate::DoThrow [e:\derek\chromium\src\v8\src\isolate.cc:1088](0x6c5ad756 rethrowing_message_"

ThreadLocalTop thread_local_top_;

Not a bitfield:
bool rethrowing_message_;

It is initialized in the constructor which calls
ThreadLocalTop::InitializeInternal() but the comment implies there's some
extra complexity here:
// These members are re-initialized later after deserialization
// is complete.
...
rethrowing_message_ = false;

107 6b48f18f 66c741100000 mov word ptr [ecx+10h],0

Local var in windbg is bogus (this is Release build) so reconstructing from:
Error `#1`: UNINITIALIZED READ: reading 0x03fecd7d-0x03fecd7e 1 byte(s)

+0x1b04 thread_local_top_ : v8::internal::ThreadLocalTop
0:006> dt v8::internal::ThreadLocalTop 03fecd7d-11
+0x000 isolate_ : 0x03feb268 v8::internal::Isolate
+0x004 context_ : 0x0713ae49 v8::internal::Context
+0x008 thread_id_ : v8::internal::ThreadId
+0x00c pending_exception_ : 0x071080a1 v8::internal::Object
+0x010 has_pending_message_ : 0
+0x011 rethrowing_message_ : 0
+0x014 pending_message_obj_ : 0x071080a1 v8::internal::Object

0:006> dd 03fecd7d-11
03fecd6c 03feb268 0713ae49 00000002 071080a1
03fecd7c 00000000 071080a1 071080a1 00000000
0:006> dyb @@(((char *)drmemorylib!umbra_map->shadow_table[0x03fe])) + (0x03fecd7d/4)) L10
76543210 76543210 76543210 76543210
-------- -------- -------- --------
281f0e83 11110000 00000000 00000000 11111111 f0 00 00 ff
281f0e87 11111111 00000000 11111100 00000000 ff 00 fc 00
281f0e8b 00000000 00000000 00000000 00000000 00 00 00 00
281f0e8f 00000000 00000000 11111111 00000000 00 00 ff 00

Failure\* IC::TypeError(const char\* type,
...
return isolate()->Throw(*error);

Isolate\* isolate() const { return isolate_; }

Isolate\* isolate_;

IC::IC(FrameDepth depth, Isolate\* isolate)
: isolate_(isolate),

InitializeInternal is also called here:
0:006> kn
# ChildEBP RetAddr
00 03aff6d8 6b93f270 v8!v8::internal::ThreadLocalTop::InitializeInternal+0x65 [e:\derek\chromium\src\v8\src\isolate.cc @ 109]
01 03aff6e0 6b93eb69 v8!v8::internal::Isolate::InitializeThreadLocal+0x10 [e:\derek\chromium\src\v8\src\isolate.cc @ 1794]
02 03aff728 6b95ce3c v8!v8::internal::Isolate::Init+0x669 [e:\derek\chromium\src\v8\src\isolate.cc @ 1957]
03 03aff734 6b98e04d v8!v8::internal::V8::Initialize+0x7c [e:\derek\chromium\src\v8\src\v8.cc @ 90]
04 03aff830 6b880c0e v8!v8::internal::Snapshot::Initialize+0x17d [e:\derek\chromium\src\v8\src\snapshot-common.cc @ 112]

Those two bools (0x10, 0x11) are also written at these spots:

v8!v8::internal::Isolate::Init+0x807 [e:\derek\chromium\src\v8\src\isolate.cc @ 2006]:
6b93ed07 c687141b000000 mov byte ptr [edi+1B14h],0

v8!v8::internal::Invoke+0x1e7 [e:\derek\chromium\src\v8\src\execution.cc @ 114]:
6b8c8117 c687141b000000 mov byte ptr [edi+1B14h],0

v8!v8::internal::Isolate::ReportPendingMessages+0x184 [e:\derek\chromium\src\v8\src\isolate.cc @ 1280]:
6b940714 c686141b000000 mov byte ptr [esi+1B14h],0

generated code:
2ca472ad 5a pop edx
2ca472ae d1fa sar edx,1
2ca472b0 8915142dc900 mov dword ptr ds:[0C92D14h],edx
edx=3aad0000

Maybe it came from that sar? The top 2 bytes are uninit, and the sar
marks the 2nd byte (rethrowing_message_) as uninit, when in reality
perhaps that bit shifted in is defined?

Prior gen code:
0:006> U 2ca47274 L12
2ca47274 8b15142dc900 mov edx,dword ptr ds:[0C92D14h]
2ca4727a 03d2 add edx,edx
2ca4727c 52 push edx
2ca4727d 8b151c2dc900 mov edx,dword ptr ds:[0C92D1Ch]
2ca47283 52 push edx
2ca47284 8b45f0 mov eax,dword ptr [ebp-10h]
2ca47287 e894b8fcff call 2ca12b20
2ca4728c 85c0 test eax,eax
2ca4728e 0f8412000000 je 2ca472a6
2ca47294 ff750c push dword ptr [ebp+0Ch]
2ca47297 b801000000 mov eax,1
2ca4729c bbd0fb8f6b mov ebx,offset v8!v8::internal::Runtime_EnableAccessChecks (6b8ffbd0)
2ca472a1 e8fa2dfcff call 2ca0a0a0
2ca472a6 5a pop edx
2ca472a7 89151c2dc900 mov dword ptr ds:[0C92D1Ch],edx
2ca472ad 5a pop edx
2ca472ae d1fa sar edx,1
2ca472b0 8915142dc900 mov dword ptr ds:[0C92D14h],edx

The 2nd call ends in a jmp -- so it's not simple to analyze statically,
but it looks like it takes the two bools, doubles them (add edx,edx), and
then divides by 2 (sar edx,1).

It looks that way: breaking on the add edx,edx, it starts out as what it
ends up as: edx=3aad0000. The pushed value is not read until that pop,
followed by the sar. Very strange to multiply or shift a dword consisting
of two bools

Indeed, if I eliminate OP_sar slowpath actions, the uninit goes away.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1526_