DynamoRIO / drmemory

Memory Debugger for Windows, Linux, Mac, and Android
Other
2.42k stars 261 forks source link

fedora test-suite fails on fresh base #1265

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From brandenj...@gmail.com on June 08, 2013 00:59:58

Both my fedora 18 and fedora 15 builds are encountering this. both x64. f18 requires revisions mentioned in issue #1259 and in order to build. The f15 was fresh. I used the same script

dependencies

sudo yum groupinstall -y --skip-broken "Development Tools" sudo yum install -y --skip-broken git-svn.x86_64 cmake make gcc gcc-c++ glibc-devel.* libgcc.* git-svn.noarch libstdc++.* libstdc++-devel* mesa-libGLU-devel.*

on both. I had a fedora 17 system that I made this script on, but it's tests pass. mesa-libGLU-devel was an addition for my f18, it is also installed on f15, but not on f17. I'm sure I had to install some other things besides what is above to get the build working.

these fails are common between my f15 and f18 dbg-32 test.

unix_syscalls => failed to match unix_syscalls.c:63, found unix_syscalls.c:12 instead suppress => stderr failed to match Dr.M 1 unique, 1 total uninitialized access(es), found Dr.M 3 unique, 3 total uninitialized access(es) instead suppress-genoffs suppress-gensyms perturb_FLAKY => Application /home/branden/Downloads/build/build_suite/build_drmemory-dbg-32/tests/pthreads (12022). Internal Error Internal DynamoRIO Error: /home/branden/Downloads/drmemory/dynamorio/core/dynamo.c:1139 ok; (12022). Internal Error Internal DynamoRIO Error:

In addition, f18 fails pthread_test and clone. And also realloc in release ver. While f15 fails free.

All 64-bit tests pass on both.

A quick summary of the each fail from f18 dbg-32 last-test

12:unix_syscalls -----failed to match "unix_syscalls.c:63", found "unix_syscalls.c:12" instead -----12 is 123/125 13:clone -----dynamorio/core/synch.c:194 res 15:pthread_test -----dynamorio/core/synch.c:194 res 33:suppress -----stderr failed to match "Dr.M 1 unique, 1 total uninitialized -----access(es)", found "Dr.M 3 unique, 3 total uninitialized access(es)" -----instead 34:suppress-genoffs -----failed to match "suppress!syscall_test" 35:suppress-gensyms -----failed to match "suppress!syscall_test" 36:perturb_FLAKY --pthread_test -----dynamorio/core/synch.c:194 res

attached is LastTest file from dbg-32 testsuite.

Attachment: LastTest_20130607-2105.log

Original issue: http://code.google.com/p/drmemory/issues/detail?id=1265

derekbruening commented 9 years ago

From bruen...@google.com on June 08, 2013 06:49:13

FTR I have FC17 and perturb_FLAKY ( issue #715 ) is normally the only failure:

drheapstat-dbg-32: all 28 tests passed drheapstat-rel-32: all 28 tests passed drmemory-dbg-32: all 52 tests passed drmemory-dbg-64: all 5 tests passed drmemory-rel-32: 51 tests passed, \ 1 tests failed, of which 1 were flaky: ** perturb_FLAKY drmemory-rel-64: all 5 tests passed final package: build successful; no tests for this build

Status: Accepted
Owner: brandenj...@gmail.com

derekbruening commented 9 years ago

From bruen...@google.com on June 10, 2013 11:28:55

\ TODO unix-syscalls unaddr missing frame

Error #1: UNADDRESSABLE ACCESS: reading 10 byte(s)

0 system call open

1 libc.so.6!__GI___libc_open (0x49b7fa13 <libc.so.6+0xe4a13>) modid:3

2 main [/home/branden/Repositories/DrMem/drmemory/tests/unix_syscalls.c:123](0x08048eb1 <unix_syscalls+0xeb1) modid:1

missing unaddr_open() call

callstack stack pc=0x51908ac0 xsp=0xffcff390 xbp=0x00000000: 0xffcff390 0xffcff3d8 0xffcff394 0x49b7fa13 libc.so.6!GI___libc_open 0xffcff398 0x49c4d000 libc.so.6!? 0xffcff39c 0x08048a03 unix_syscalls!unaddr_open 0xffcff3a0 0x083ba418 0xffcff3a4 0x00000001 0xffcff3a8 0xffffffff 0xffcff3ac 0x49accff3 libc.so.6!new_exitfn 0xffcff3b0 0x49aa7a3c libc.so.6!? 0xffcff3b4 0xf775ab68 0xffcff3b8 0x73797380 0xffcff3bc 0x642f6163 0xffcff3c0 0x6e2f7665 0xffcff3c4 0x006c6c75 0xffcff3c8 0x00000007 0xffcff3cc 0x083ba018 0xffcff3d0 0x00000001 0xffcff3d4 0xffcff494 0xffcff3d8 0xffcff3f8 0xffcff3dc 0x08048eb1 unix_syscalls!main 0xffcff3e0 0x49c4d3c4 libc.so.6!exit_funcs 0xffcff3e4 0x00001000 0xffcff3e8 0x08048eeb unix_syscalls!libc_csu_init 0xffcff3ec 0x49c4d000 libc.so.6!? 0xffcff3f0 0x08048ee0 unix_syscalls!__libc_csu_init 0xffcff3f4 0x00000000 initial fp=0x00000000 vs sp=0xffcff390 def=0 find_next_fp b/c starting w/ non-fp ebp 0x00000000 (def=0 0) print_callstack: pc=0xffcff390 => FP=0xffcff3d8, RA=0x49b7fa13 print_callstack: pc=0xffcff3d8 => FP=0xffcff3f8, RA=0x08048eb1 print_callstack: pc=0xffcff3f8 => FP=0x00000000, RA=0x49ab4865 find_next_fp b/c hit zero fp

xref issue #703 : skipping over b/c of frameless func in between

=> 0x80487c0 open@plt: jmp 0x804a248 (gdb) 0x4310dd40 in open () from /lib/libc.so.6 1: x/i $pc => 0x4310dd40 : cmpl $0x0,%gs:0xc (gdb) x/10i $pc => 0x4310dd40 : cmpl $0x0,%gs:0xc 0x4310dd48 <open+8>: jne 0x4310dd6c <open+44> 0x4310dd4a <__open_nocancel>: push %ebx 0x4310dd4b <open_nocancel+1>: mov 0x10(%esp),%edx 0x4310dd4f <__open_nocancel+5>: mov 0xc(%esp),%ecx 0x4310dd53 <open_nocancel+9>: mov 0x8(%esp),%ebx 0x4310dd57 <__open_nocancel+13>: mov $0x5,%eax 0x4310dd5c <__open_nocancel+18>: call %gs:0x10 (gdb) x/10i $pc => 0xf7ffd420 <__kernel_vsyscall>: push %ecx 0xf7ffd421 <kernel_vsyscall+1>: push %edx 0xf7ffd422 <__kernel_vsyscall+2>: push %ebp 0xf7ffd423 <kernel_vsyscall+3>: mov %esp,%ebp 0xf7ffd425 <__kernel_vsyscall+5>: sysenter

so on my machien there are 2 pushes separating this fp from the ra.

but on Branden's machine it matches fp,ra: => 0xf7ffd420 <__kernel_vsyscall>: push %ebp 0xf7ffd421 <__kernel_vsyscall+1>: mov %ecx,%ebp 0xf7ffd423 <__kernel_vsyscall+3>: syscall

There is a general issue where frameless func that calls a func w/ frame will cause a skip hit in issue #703 , probably elsewhere. Here this should be a common pattern, could add heuristic: if in 32-bit linux syscall, ignore fp at TOS, or sthg. A little hacky, but more general solns (debug info, e.g.) are too costly.

derekbruening commented 9 years ago

From brandenj...@gmail.com on June 10, 2013 12:21:40

^same idea on the suppress fail showing 2 errors that should be suppressed, but aren't due to missing frames. from suppressB.lin.suppress

UNINITIALIZED READ name=single * for syscall * ... suppress!syscall_test suppress!run_some_again

Reported Error: Error #3: UNINITIALIZED READ: reading 0x09ba7c00-0x09ba7c04 4 byte(s) within 0x09ba7c00-0x09ba7c04

0 system call write parameter #1

<system call>

1 libc.so.6!__GI___libc_write (0x49b7ff43 <libc.so.6+0xe4f43>)

??:0

2 suppress!run_some_again (0x08048ea7 <suppress+0xea7>)

/home/branden/Repositories/DrMem/drmemory/tests/suppress.c:388

3 suppress!main (0x08048edf <suppress+0xedf>)

/home/branden/Repositories/DrMem/drmemory/tests/suppress.c:396

In this case write_nocancel is used. callstack stack pc=0x506e5bf8 xsp=0xffaf2410 xbp=0x00000000: 0xffaf2410 0xffaf2448 0xffaf2414 0x49b7ff43 libc.so.6!_GIlibc_write 0xffaf2418 0x49c4d000 libc.so.6!? 0xffaf241c 0x08048b5a suppress!syscall_test ....

derekbruening commented 9 years ago

From bruen...@google.com on June 19, 2013 14:20:27

The SIGBUS (leading to the synch.c assert) is presumed to be a DR bug and is thus on the DR tracker: https://code.google.com/p/dynamorio/issues/detail?id=1193