Open Alexolut opened 7 years ago
Does passing -debug
or -dr_debug
provide further/different information?
Which of the steps at https://github.com/DynamoRIO/drmemory/wiki/Debugging#narrowing-down-the-source-of-the-problem work and which don't?
Passing -debug
leads to error message:
---------------------------
Dr. Memory Notice: G:\prog.exe(1720)
---------------------------
ASSERT FAILURE (thread 6820): D:\drmemory_package\drmemory\fastpath_x86.c:3511: ALIGNED(diff, mi->memsz) (can only share aligned references)
---------------------------
Passing -dr_debug
:
---------------------------
Dr. Memory Notice: G:\prog.exe(6420)
---------------------------
Application G:\prog.exe (6420). Dr. Memory internal crash at PC 0x1436cf11. Please report this at http://drmemory.org/issues. Program aborted.
0xc0000005 0x00000000 0x1436cf11 0x1436cf11 0x00000001 0xccccccd4
Base: 0x142a0000
Registers: eax=0x2567b6da ebx=0x00000206 ecx=0x256739f0 edx=0xcccccccc
esi=0x000003cc edi=0x1e267540 esp=0x1e2addc8 ebp=0x1e2addd4
eflags=0x000
1.11.0-2-(Aug 29 2016 02:42:07) win61
-no_dynamic_options -disasm_mask 8 -logdir 'C:\Users\username\AppData\Roaming\Dr. Memory\dynamorio' -client_lib 'C:\Program Files (x86)\Dr. Memory\bin\release\drmemorylib.dll;0;-logdir `C:\Users\username\AppData\Roaming\Dr. Memory` -symcache_dir `C:\Users\username\AppData\Roaming\Dr. Memory\symcache` -lib_blacklist `C:\Wind
0x1e2addd4 0x143897cf
0x1e2ae04c 0x1436d834
0x1e2ae170 0x1436d578
0x1e2ae1fc 0x14325dd9
0x1e2ae348 0x143c0a8a
0x1e2aed20 0x143c67d8
0x1e2aed48 0x1452fc8d
0x1e2aef00 0x143a86dd
0x1e2aeff4 0x1e2721fe
0x01a4e804 0x00737e18
0x01a4e850 0x00741983
0x01a4e87c 0x00742406
0x01a4e8a8 0x007421c1
0x01a4e910 0x00756c8a
0x01a4e96c 0x007462f2
---------------------------
Worth noting that prog.exe
is evolving and I used latest (different from which I use in first bug report) version of it for current run.
-no_count_leaks
produces crash:
---------------------------
Dr. Memory Notice: G:\prog.exe(9884)
---------------------------
Application G:\prog.exe (9884). Dr. Memory internal crash at PC 0x70f2abbc. Please report this at http://drmemory.org/issues. Program aborted.
0xc0000005 0x00000000 0x70f2abbc 0x70f2abbc 0x00000001 0xf16f3b94
Base: 0x70ef0000
Registers: eax=0xf16f3b8c ebx=0x00006f36 ecx=0x280eeed0 edx=0x280eeed0
esi=0x280ddcdc edi=0x203e1020 esp=0x2045ee14 ebp=0x00000000
eflags=0x000
1.11.0-2-(Aug 29 2016 02:42:07) win61
-no_dynamic_options -disasm_mask 8 -logdir 'C:\Users\username\AppData\Roaming\Dr. Memory\dynamorio' -client_lib 'C:\Program Files (x86)\Dr. Memory\bin\release\drmemorylib.dll;0;`-no_count_leaks` -logdir `C:\Users\username\AppData\Roaming\Dr. Memory` -symcache_dir `C:\Users\username\AppData\Roaming\Dr. Memory\symcache` -lib_
---------------------------
-light
option works fine (e.g. no crash).
With -leaks_only
option program hangs for a long time. Killed manually after more than 10 mins.
-leaks_only -no_count_leaks
and -leaks_only -no_count_leaks -no_track_allocs
work fine.
Please try running with the option -no_share_xl8
Works fine with this option.
The -debug
assert indicates a bug in the -share_xl8
performance optimization. Please use -no_share_xl8
as a workaround for now. It will not negatively affect any error reporting.
Would it be possible to get access to either this application or if it's short-running to the log files (the sub-directory created inside drmemory\logs
) from a -debug -verbose 3
run?
Sorry, but I can't share this application due to NDA. This is a large and complicated application with GUI and requires hardware key for running. But I can run it on my PC with any test that you will suggest.
In order to fix this we need to see the disassembly of the basic block where the problem is hit. If you could attach the windbg debugger at the ASSERT point, load our symbols, find the start address of the block from a parent function, and provide the disassembly here, then we should be able to reproduce by making a test with just that block. Load the symbols using the load_syms
script described at https://github.com/DynamoRIO/drmemory/wiki/Debugging#windows. With a callstack, the start address should be there as a parameter to a caller up the callstack: the 2nd parameter start
to build_basic_block_fragment
.