<div dir="ltr">Yes, both JIT code and the native runtime are instrumented. I am under the impressions that the the C library should guarantee that from the way the relocations are implemented as long as both native and JITed code are on the same thread (but I will verify this and report back). </div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 2:41 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I assume there are transitions between JITted code and native helper<br>
functions. How are you handling them? Are native functions<br>
MSan-instrumented?<br>
MSan is passing shadow across function calls in TLS slots. Does your<br>
TLS implementation guarantee that accesses to __msan_param_tls from<br>
JITted and from native code map to the same memory?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov<br>
<<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
> This is really cool. I've not heard of anyone using MSan with MSJIT before.<br>
><br>
><br>
> On Mon, Jan 27, 2014 at 7:44 PM, Keno Fischer<br>
> <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
>> Hello everybody,<br>
>><br>
>> I've run into some strange behavior with memory sanitizer that I can't<br>
>> explain and hope somebody with more knowledge of the implementation would be<br>
>> able to help me out or at least point me into the right direction.<br>
>><br>
>> For background, I'm using memory sanitizer to check Julia (<a href="http://julialang.org" target="_blank">julialang.org</a>),<br>
>> which uses (or at least will once I track down a few bugs) MCJIT for the<br>
>> code compilation. So far I have rebuilt the runtime and all dependencies<br>
>> (including LLVM, libcxx, etc.) with memory sanitizer enabled and added the<br>
>> instrumentation pass in the appropriate place in the julia code generator.<br>
>><br>
>> I'm now going through the usual bootstrap which basically loads the standard<br>
>> library and compiles it, does inference, etc. This works fine for several<br>
>> hours (this is usually much faster - by which I mean several hundred time -<br>
>> I suspect the issue is with MCJIT having to process a ton more relocations<br>
>> and code and being inefficient at it, but I can't prove that). That's not<br>
>> the issue however. Eventually, I get<br>
>><br>
>> ==17150== WARNING: MemorySanitizer: use-of-uninitialized-value<br>
>> #0 0x7f417cea3189 in bitvector_any1<br>
>> /home/kfischer/julia-san/src/support/bitvector.c:177<br>
>> [ snip ]<br>
>><br>
>> Uninitialized value was created by a heap allocation<br>
>> #0 0x7f41815de543 in __interceptor_malloc<br>
>> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854<br>
>> #1 0x7f417cc7d7f1 in alloc_big /home/kfischer/julia-san/src/gc.c:355<br>
>> [snip]<br>
>><br>
>> Now, by going through it in the debugger, I see<br>
>><br>
>> (gdb) f 3<br>
>> #3 0x00007f417cea318a in bitvector_any1 (b=0x60c000607240,<br>
>> b@entry=<optimized out>, offs=0, offs@entry=<optimized out>, nbits=256,<br>
>> nbits@entry=<optimized out>)<br>
>> at bitvector.c:177<br>
>> 177 if ((b[0] & mask) != 0) return 1;<br>
>> (gdb) p __msan_print_shadow(&b,8)<br>
>> ff ff ff ff ff ff ff ff<br>
>> o: 3f0010a6 o: 80007666<br>
>><br>
>> which seems to indicate that the local variable b has uninitialized data.<br>
>> I'm having a hard time believing that though, since if I look at the<br>
>> functions before it, the place where it's coming from is initialized:<br>
>><br>
>> #4 0x00007f41755208a8 in julia_isempty248 ()<br>
>> #5 0x00007f417c163e3d in jl_apply (f=0x606000984d60, f@entry=<optimized<br>
>> out>, args=0x7fff9132da20, args@entry=<optimized out>, nargs=1,<br>
>> nargs@entry=<optimized out>) at ./julia.h:1043<br>
>><br>
>> (here's the code of that julia function for reference)<br>
>><br>
>> isempty(s::IntSet) =<br>
>> !s.fill1s && ccall(:bitvector_any1, Uint32, (Ptr{Uint32}, Uint64,<br>
>> Uint64), s.bits, 0, s.limit)==0<br>
>><br>
>> Looking at where that value is coming from:<br>
>><br>
>> (gdb) f 5<br>
>> #5 0x00007f417c163e3d in jl_apply (f=0x606000984d60, f@entry=<optimized<br>
>> out>, args=0x7fff9132da20, args@entry=<optimized out>, nargs=1,<br>
>> nargs@entry=<optimized out>) at ./julia.h:1043<br>
>> 1043 return f->fptr((jl_value_t*)f, args, nargs);<br>
>> (gdb) p ((jl_array_t*)((void**)args[0])[1])->data<br>
>> $43 = (void *) 0x60c000607240<br>
>> (gdb) p __msan_print_shadow(((jl_array_t*)((void**)args[0])[1]),0x30)<br>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br>
>> o: d800496 o: d800496 o: d800496 o: d800496 o: d800496 o: d800496 o:<br>
>> d800496 o: d800496 o: d800496 o: d800496 o: d800496 o: d800496<br>
>><br>
>> There are no uninitialized values to be seen anywhere and the `b` value<br>
>> isn't touched before that line, so I'm a little stumped.<br>
>><br>
>> One note I should make is that I did have to implement TLS support myself in<br>
>> MCJIT for this to work (I'll upstream the patch soon), so I may have made a<br>
>> mistake, but I haven't found anything wrong yet. If nothing looks unusual,<br>
>> I'd also appreciate pointers on what to look for in the TLS variables.<br>
>><br>
>> Thank you for your help,<br>
>> Keno<br>
>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>><br>
</div></div></blockquote></div><br></div>