Displaying 3 results from an estimated 3 matches for "40000e23".
Did you mean:
40000003
2014 Feb 05
2
[LLVMdev] Weird msan problem
...box_voidpointer(v);
> 286 assert(__msan_test_shadow(&ptr,sizeof(void**)) == -1);
> 287 return (void*)ptr;
> 288 }
> 289 }
> 290
> (gdb) p __msan_print_shadow(v,16)
> 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
> o: 40000e23 o: 40000e23 o: 40000e23 o: 40000e23
> $21 = void
> (gdb) p __msan_print_shadow(&ptr,8)
> ff ff ff ff ff ff ff ff
> o: 40000e23 o: 80007614
> $22 = void
>
> Notice the origin of the lower bits is off. Any idea as to why?
>
>
> On Mon, Feb 3, 2014 at 2:52 AM, Ev...
2014 Feb 07
2
[LLVMdev] Weird msan problem
...ow(&ptr,sizeof(void**)) ==
> -1);
> >> 287 return (void*)ptr;
> >> 288 }
> >> 289 }
> >> 290
> >> (gdb) p __msan_print_shadow(v,16)
> >> 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ff ff
> >> o: 40000e23 o: 40000e23 o: 40000e23 o: 40000e23
> >> $21 = void
> >> (gdb) p __msan_print_shadow(&ptr,8)
> >> ff ff ff ff ff ff ff ff
> >> o: 40000e23 o: 80007614
> >> $22 = void
> >>
> >> Notice the origin of the lower bits is off. Any id...
2014 Feb 03
2
[LLVMdev] Weird msan problem
The code for ccall looks right. Sounds like you have a very small
range of instructions where an uninitialized value appear. You could
try debugging at asm level. Shadow for b should be passed at offset 0
in __msan_param_tls.
MSan could propagate shadow through arithmetic and even some logic
operations (like select). It could be that b is clean on function
entry, but then something uninitialized