ScaleFilterCols_C @ 225 is this line, which I saw reading 0x0018bb58 when running
in the debugger:
dst_ptr[0] = BLENDER(a, b, x & 0xffff);
so it seems that slowpath is right and fastpath should report this!
binary search => OP_sar is the culprit
if (opc == OP_sar) {//NOCHECKIN
static int count;
count++;
if (count > 147 && count < 149) {
LOG(1, "bad OP_sar @"PFX"\n", instr_get_app_pc(inst));
// return false;
}
}
this one:
bad OP_sar @0x005a9a41
% ~/drmemory/git/build_x86_dbg/bin/symquery.exe -e libyuv_unittest.exe -f -a 0x1a9a41
ScaleFilterCols_C+0x101
d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\source\scale_common.cc:225+0x11
From bruen...@google.com on December 06, 2013 18:33:34
-no_fastpath on libyuv_unittest.exe from issue #1396 has extra uninits beyond what the fastpath shows.
It has the 2 movd from issue #1396 plus 2 more like this:
Error
#3
: UNINITIALIZED READ: reading 0x0018fc3c-0x0018fc3d 1 byte(s) within 0x0018fc3c-0x0018fc400 MSVCR100D.dll!abs (0x63a42126 <MSVCR100D.dll+0x122126>) modid:3
1 libyuv::libyuvTest_I411ToI420_Any_Test::TestBody [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\unit_test\convert_test.cc:165](0x0042dd6c <libyuv_unittest.exe+0x2dd6c) modid:1
2 testing::internal::HandleExceptionsInMethodIfSupportedtesting::Test,void [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:2051](0x005beac5 <libyuv_unittest.exe+0x1beac5) modid:1
3 testing::Test::Run [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:2068](0x005afbe7 <libyuv_unittest.exe+0x1afbe7) modid:1
4 testing::TestInfo::Run [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:2244](0x005b037d <libyuv_unittest.exe+0x1b037d) modid:1
5 testing::TestCase::Run [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:2351](0x005b098f <libyuv_unittest.exe+0x1b098f) modid:1
6 testing::internal::UnitTestImpl::RunAllTests [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:4177](0x005b5a7e <libyuv_unittest.exe+0x1b5a7e) modid:1
7 testing::internal::HandleExceptionsInMethodIfSupportedtesting::internal::UnitTestImpl,bool [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:2051](0x005bf3dd <libyuv_unittest.exe+0x1bf3dd) modid:1
8 testing::UnitTest::Run [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\testing\gtest\src\gtest.cc:3812](0x005b49b6 <libyuv_unittest.exe+0x1b49b6) modid:1
9 main [d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\unit_test\unit_test.cc:54](0x0058627f <libyuv_unittest.exe+0x18627f) modid:1
Note: @0:00:17.900 in thread 6716 Note: instruction: cmp 0x08(%ebp) $0x00000000 error end
slow_path 0x63982126: cmp 0x08(%ebp) $0x00000000 shadow registers prior to instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff memref: read @0x63982126 0x0018fc3c 0x4 bytes (pre-dword 0x03 0x00)
so it's the arg to abs(). here it's passed:
slow_path 0x0042dd64: sub %eax %ecx -> %ecx shadow registers prior to instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 shadow_vals after src 0 %eax : 00000000000000000000000000000000 shadow_vals after src 1 %ecx : 30000000000000000000000000000000 shadow registers after instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff
slow_path 0x0042dd66: push %ecx %esp -> %esp 0xfffffffc(%esp) shadow registers prior to instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff shadow_vals after src 0 %ecx : 30000000000000000000000000000000 shadow_vals after src 1 %esp : 30000000000000000000000000000000 memref: push @0x0042dd66 0x0018fc3c 0x4 bytes (pre-dword 0x55 0x00) in slow path for unknown reason @0x0042dd66 0x0018fc3c shadow registers after instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff
came from here: slow_path 0x0042dd41: movzx (%ecx,%eax,1) -> %ecx shadow registers prior to instr: eax=00 ecx=00 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 memref: read @0x0042dd41 0x013e0e0e 0x1 bytes (pre-dword 0x30 0x00) shadow_vals after src 0 (%ecx,%eax,1) : 30000000000000000000000000000000 shadow registers after instr: eax=00 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 % ~/drmemory/git/build_x86_dbg/bin/symquery.exe -e libyuv_unittest.exe -f -a 0x2dd41 libyuv::libyuvTest_I411ToI420_Any_Test::TestBody+0x611 d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\unit_test\convert_test.cc:165+0x611
written here: slow_path 0x005a9a4a: mov %al -> (%edx) | 0x3 shadow registers prior to instr: eax=03 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff shadow_vals after src 0 %al : 30000000000000000000000000000000 memref: write @0x005a9a4a 0x013e0e0e 0x1 bytes (pre-dword 0xf0 0xff) store @0x005a9a4a to 0x013e0e0e w/ already-same-val 0x3 in slow path for unknown reason @0x005a9a4a 0x013e0e0e shadow registers after instr: eax=03 ecx=03 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff % ~/drmemory/git/build_x86_dbg/bin/symquery.exe -e libyuv_unittest.exe -f -a 0x1a9a4a ScaleFilterCols_C+0x10a d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\source\scale_common.cc:225+0x1a
and al became uninit from ecx here: slow_path 0x005a9a3e: imul %ecx %eax -> %eax shadow registers prior to instr: eax=00 ecx=03 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff shadow_vals after src 0 %ecx : 30000000000000000000000000000000 shadow_vals after src 1 %eax : 30000000000000000000000000000000 shadow registers after instr: eax=03 ecx=03 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=ff
ecx came from here: slow_path 0x005a9a38: mov 0xffffffe8(%ebp) -> %ecx shadow registers prior to instr: eax=00 ecx=00 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 memref: read @0x005a9a38 0x0018bb1c 0x4 bytes (pre-dword 0x03 0x00) shadow_vals after src 0 0xffffffe8(%ebp) : 30000000000000000000000000000000 shadow registers after instr: eax=00 ecx=03 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0
written here: slow_path 0x005a9a2d: mov %edx -> 0xffffffe8(%ebp) | 0x3 shadow registers prior to instr: eax=00 ecx=00 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 shadow_vals after src 0 %edx : 30000000000000000000000000000000 memref: write @0x005a9a2d 0x0018bb1c 0x4 bytes (pre-dword 0xff 0x00) store @0x005a9a2d to 0x0018bb1c w/ already-same-val 0x3 store @0x005a9a2d to 0x0018bb1d val=0x0 store @0x005a9a2d to 0x0018bb1e val=0x0 store @0x005a9a2d to 0x0018bb1f val=0x0 in slow path for unknown reason @0x005a9a2d 0x0018bb1c shadow registers after instr: eax=00 ecx=00 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0
edx came from here: slow_path 0x005a9a29: movzx 0x01(%ecx) -> %edx shadow registers prior to instr: eax=00 ecx=00 edx=00 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 memref: read @0x005a9a29 0x0018bb58 0x1 bytes (pre-dword 0xff 0xff) shadow_vals after src 0 0x01(%ecx) : 30000000000000000000000000000000 shadow registers after instr: eax=00 ecx=00 edx=03 ebx=00 esp=00 ebp=00 esi=00 edi=00 efl=0 % ~/drmemory/git/build_x86_dbg/bin/symquery.exe -e libyuv_unittest.exe -f -a 0x1a9a29 ScaleFilterCols_C+0xe9 d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\source\scale_common.cc:224+0x6
hmm, there's 0x0018bb58 again.
ScaleFilterCols_C @ 225 is this line, which I saw reading 0x0018bb58 when running in the debugger: dst_ptr[0] = BLENDER(a, b, x & 0xffff);
so it seems that slowpath is right and fastpath should report this!
binary search => OP_sar is the culprit if (opc == OP_sar) {//NOCHECKIN static int count; count++; if (count > 147 && count < 149) { LOG(1, "bad OP_sar @"PFX"\n", instr_get_app_pc(inst)); // return false; } }
this one: bad OP_sar @0x005a9a41 % ~/drmemory/git/build_x86_dbg/bin/symquery.exe -e libyuv_unittest.exe -f -a 0x1a9a41 ScaleFilterCols_C+0x101 d:\derek\drmemory\bugs\i1396-libyuv\libyuv\trunk\source\scale_common.cc:225+0x11
TAG 0x005a9a0e +0 L3 8b 4d 14 mov 0x14(%ebp) -> %ecx +3 L3 c1 f9 10 sar $0x00000010 %ecx -> %ecx +6 L3 89 4d e4 mov %ecx -> 0xffffffe4(%ebp) +9 L3 8b 55 0c mov 0x0c(%ebp) -> %edx +12 L3 03 55 e4 add 0xffffffe4(%ebp) %edx -> %edx +15 L3 0f b6 02 movzx (%edx) -> %eax +18 L3 89 45 ec mov %eax -> 0xffffffec(%ebp) +21 L3 8b 4d 0c mov 0x0c(%ebp) -> %ecx +24 L3 03 4d e4 add 0xffffffe4(%ebp) %ecx -> %ecx +27 L3 0f b6 51 01 movzx 0x01(%ecx) -> %edx +31 L3 89 55 e8 mov %edx -> 0xffffffe8(%ebp) +34 L3 8b 45 14 mov 0x14(%ebp) -> %eax +37 L3 25 ff ff 00 00 and $0x0000ffff %eax -> %eax +42 L3 8b 4d e8 mov 0xffffffe8(%ebp) -> %ecx +45 L3 2b 4d ec sub 0xffffffec(%ebp) %ecx -> %ecx +48 L3 0f af c1 imul %ecx %eax -> %eax +51 L3 c1 f8 10 sar $0x00000010 %eax -> %eax +54 L3 03 45 ec add 0xffffffec(%ebp) %eax -> %eax +57 L3 8b 55 08 mov 0x08(%ebp) -> %edx +60 ...
Original issue: http://code.google.com/p/drmemory/issues/detail?id=1399