Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CRASH at end of net_unittests #1722

Closed
derekbruening opened this issue May 4, 2015 · 0 comments
Closed

CRASH at end of net_unittests #1722

derekbruening opened this issue May 4, 2015 · 0 comments

Comments

@derekbruening
Copy link
Contributor

DrMem is crashing at the end of net_unittests:

http://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Unit%20%28DrMemory%20full%29%20%281%29/builds/699/steps/memory%20test%3A%20net/logs/stdio

[==========] 3933 tests from 442 test cases ran. (703785 ms total)
[  PASSED  ] 3933 tests.

  YOU HAVE 57 DISABLED TESTS

<Application E:\b\build\slave\chromium-dbg-win-drmemory-full-1\build\src\out\Release\net_unittests.exe (3148).  Dr. Memory internal crash at PC 0x6bc95f81.  Please report this at http://drmemory.org/issues.  Program aborted.
0xc0000005 0x00000000 0x6bc95f81 0x6bc95f81 0x00000001 0x00000000
Base: 0x6bc20000
Registers: eax=0x6bcf98a0 ebx=0x00000000 ecx=0x000000eb edx=0x00000000
    esi=0x1c970798 edi=0x1c970798 esp=0x1c11eda0 ebp=0x1c11edb4
    eflags=0x000
version 5.0.2850, custom build
-no_dynamic_options -disasm_mask 8 -logdir 'C:\Users\chrome-bot\AppData\LocalLow\vg_logs_pejsj9\dynamorio' -client_lib 'E:\b\build\slave\chromium-dbg-win-drmemory-full-1\build\src\third_party\drmemory\unpacked\bin\release\drmemorylib.dll;0;-suppress `E:\b\build\slave\chromium-dbg-win-drmemory-full-1\build\src\tools\valgrind\drmemory\suppressions.txt` -suppress `E:\b\build\slave\c
0x1c11edb4 0x6bc961c6
0x1c11ee28 0x6bc966a8
0x1c11ee44 0x6bc64510
0x1c11ee74 0x6bc64883
0x1c11eed8 0x6bc64f76
0x1c11ef00 0x6bcaca01
0x1c11efa0 0x6bc64136
0x1c11eff4 0x1c0e1be6
0x003af868 0x772b99a0
0x003af888 0x772fdc49
0x003af8cc 0x772f0aca
0x003af968 0x772cd5a4
0x003af97c 0x74ff79ed
0x003af990 0x6cbd3fac
0x003af99c 0x6cbd427e>
~~Dr.M~~ WARNING: application exited with abnormal code 0xffffffff

I can reproduce running just A* subtests. Details:

DR debug:

[  PASSED  ] 26 tests.
<Application Z:\derek\chromium\src\out\Release\net_unittests.exe (7424) DynamoRIO usage error : instr_encode error: no encoding found (see log)>
dispatch: target = 0x670e3b7e
Fragment 115907, tag 0x670e3b7e, flags 0x1000030, shared, size 332:
        [boringssl.dll~PROXY_CERT_INFO_EXTENSION_free+0x6f820,~ASN1_TIME_it-0x552a6]
Entry into F115907(0x670e3b7e).0x2e81de9b (shared)
Exit from sourceless ibl: bb ret        []
 (target 0x670e3b8b not in cache)

dispatch: target = 0x670e3b8b
ERROR: Could not find encoding for: cmp    %fs:0x00000edc[4byte] $0x00005555
0:000> U 0x670e3b8b L20
boringssl!thread_local_destructor+0x5b [z:\derek\chromium\src\third_party\boringssl\src\crypto\thread_win.c @ 171]:
670e3b8b f30f7e051c381767 movq    xmm0,mmword ptr [boringssl!g_destructors (6717381c)]
670e3b93 8b0d24381767    mov     ecx,dword ptr [boringssl!g_destructors+0x8 (67173824)]
670e3b99 6804381767      push    offset boringssl!g_destructors_lock (67173804)
670e3b9e 660fd645f0      movq    mmword ptr [ebp-10h],xmm0
670e3ba3 894df8          mov     dword ptr [ebp-8],ecx
670e3ba6 ff1574501767    call    dword ptr [boringssl!_imp__LeaveCriticalSection (67175074)]

in event_basic_block(tag=0x670e3b8b)
inside heap routine: adding nop-if-mem-unaddr checks

Can't repro w/ similar instr sequence in asmtest. The "inside heap routine" is due to:

entering alloc routine 0x77ea9c8d LdrShutdownProcess type=52 rec=0 adj=0

Custom logging for this bb:

 <...>
 +300  L3              68 04 38 9a 67       push   $0x679a3804 %esp -> %esp 0xfffffffc(%esp)[4byte]
 +305  m4 @0x1d73ad8c  64 89 0d c4 0e 00 00 mov    %ecx -> %fs:0x00000ec4[4byte]
 +312  m4 @0x217e9f44                       <label>
 +312  m4 @0x217eb514  8d 55 f0             lea    0xfffffff0(%ebp) -> %edx
 +315  m4 @0x1d73dab8  64 80 3d d5 0e 00 00 cmp    %fs:0x00000ed5[1byte] $0x00
                       00
 +323  m4 @0x1d73b77c  75 fe                jnz    @0x217ea730[4byte]
 +325  m4 @0x217ea95c  f6 c2 03             test   %dl $0x03
 +328  m4 @0x1d73d3a0  0f 85 fa ff ff ff    jnz    @0x217ea730[4byte]
 +334  m4 @0x217ea50c  8b c2                mov    %edx -> %eax
 +336  m4 @0x217eb324  c1 e8 10             shr    $0x00000010 %eax -> %eax
 +339  m4 @0x217e78bc  c1 ea 02             shr    $0x00000002 %edx -> %edx
 +342  m4 @0x1d73abac  03 14 85 00 be e0 73 add    0x73e0be00(,%eax,4)[4byte] %edx -> %edx
 +349  m4 @0x217e2088  64 8b 0d dc 0e 00 00 mov    %fs:0x00000edc[4byte] -> %ecx
 +356  m4 @0x217e1e00  66 8b 09             mov    (%ecx)[2byte] -> %cx
 +359  m4 @0x217e8070  66 85 c9             test   %cx %cx
 +362  m4 @0x217ea15c  0f 85 fa ff ff ff    jnz    @0x217e7e98[4byte]
 +368  m4 @0x217e7830  66 81 3a 00 00       cmp    (%edx)[2byte] $0x0000
 +373  m4 @0x217e8564  74 fe                jz     @0x217e6664[4byte]
 +375  m4 @0x1d73cc54  66 81 3a ff ff       cmp    (%edx)[2byte] $0xffff
 +380  m4 @0x1d73ce38  74 fe                jz     @0x217e6664[4byte]
 +382  m4 @0x217e9a9c  66 81 3a 00 ff       cmp    (%edx)[2byte] $0xff00
 +387  m4 @0x217e406c  74 fe                jz     @0x217e6664[4byte]
 +389  m4 @0x217e6814  66 81 3a ff 00       cmp    (%edx)[2byte] $0x00ff
 +394  m4 @0x217e8d70  75 fe                jnz    @0x217ea730[4byte]
 +396  m4 @0x217e6664                       <label>
 +396  m4 @0x217e6338  66 81 3a 00 00       cmp    (%edx)[2byte] $0x0000
 +401  m4 @0x217e22a0  74 fe                jz     @0x217e1248[4byte]
 +403  m4 @0x217e2338  66 c7 02 00 00       mov    $0x0000 -> (%edx)[2byte]
 +408  m4 @0x217e1248                       <label>
 +408  m4 @0x217e4e00                       <label>
 +408  m4 @0x1d73ac90  64 8b 0d c4 0e 00 00 mov    %fs:0x00000ec4[4byte] -> %ecx
 +415  m4 @0x217e47a0  eb fe                jmp    @0x1d73d3f8[4byte]
 +417  m4 @0x217e7e98                       <label>
 +417  m4 @0x217e8374  64 80 3d d9 0e 00 00 cmp    %fs:0x00000ed9[1byte] $0x00
                       00
 +425  m4 @0x217e696c  74 fe                jz     @0x217ea730[4byte]

scratch: push   $0x679a3804 %esp -> %esp 0xfffffffc(%esp)[4byte]| r1=%edxspill#0, r2=%eaxspill#1
fastpath: push   $0x679a3804 %esp -> %esp 0xfffffffc(%esp)[4byte]| prop=0 srcsz=0 dstsz=4 checkdef=0 markdef=
1 checkunaddr=1
in heap routine: adding nop-if-mem-unaddr checks
        src shadow = $0x00
        dst shadow = (%edx)
        src offs = $0x00
        dst offs = $0x00
scratch: movq   %xmm0[8byte] -> 0xfffffff0(%ebp)[8byte]| r1=%edxspill#0, r2=%eaxspill#1, r3=%ecxspill#3
checking definedness for: movq   %xmm0[8byte] -> 0xfffffff0(%ebp)[8byte]
fastpath: movq   %xmm0[8byte] -> 0xfffffff0(%ebp)[8byte]| prop=1 srcsz=8 dstsz=8 checkdef=1 markdef=0 checkunaddr=1
in heap routine: adding nop-if-mem-unaddr checks
        checking definedness of src1 => 0 to propagate
        src shadow = $0x0000
        dst shadow = (%edx)
        src offs = $0x00
        dst offs = $0x00

The bad cmp comes from:

                PREXL8M(bb, inst, INSTR_XL8
                        (INSTR_CREATE_cmp(drcontext, heap_unaddr_shadow,
                                          shadow_immed(mi->memsz, SHADOW_UNADDRESSABLE)),
                         mi->xl8));

TLS shadow base: 0xed0
so ed9 is in_heap_routine
edc == aux

Going back to asmtest, I can repro if I force check_ignore_unaddr.

It's only later w/ num_to_propagate==0 that src shadow is set to a constant: the heap_unaddr_shadow is from the first src0.

scratch: movq   %xmm0[8byte] -> (%eax)[8byte]| r1=%ebxspill#0, r2=%edxspill#1, r3=%ecxspill#3
checking definedness for: movq   %xmm0[8byte] -> (%eax)[8byte]
fastpath: movq   %xmm0[8byte] -> (%eax)[8byte]| prop=1 srcsz=8 dstsz=8 checkdef=1 markdef=0 checkunaddr=1
in heap routine: adding nop-if-mem-unaddr checks
        XXX B src shadow = %fs:0x00000edc
        XXX B heap_unaddr_shadow = %fs:0x00000edc
        src shadow = $0x0000
        dst shadow = (%ebx)
        src offs = $0x00
        dst offs = $0x00
        XXX src shadow = $0x0000
        XXX heap_unaddr_shadow = %fs:0x00000edc

Basically it doesn't make sense to check the src if it's an xmm: the check
should be moved to the memory, as xmm will never hold an unaddr value.

@derekbruening derekbruening self-assigned this May 4, 2015
ryumiel pushed a commit to ltilve/chromium that referenced this issue May 7, 2015
This re-lands fixes for problems handling HeapWalk().

This also fixes several other bugs:
DynamoRIO/dynamorio#1690,
DynamoRIO/drmemory#1718,
DynamoRIO/drmemory#1722, and
DynamoRIO/drmemory#1723.

BUG=481231
TBR=thakis@chromium.org
NOTRY=true

Review URL: https://codereview.chromium.org/1128923003

Cr-Commit-Position: refs/heads/master@{#328548}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant