drmemory
drmemory copied to clipboard
DynamoRIO
Calling Java HelloWorld
From saxonophon on October 17, 2011 06:55:23
I´m the author of the "Support of Java/JNI" discussion and post the error log as requested from Derek.
link to discussion: http://groups.google.com/group/drmemory-users/browse_thread/thread/1ce4ad3f17596589 What steps will reproduce the problem? 1. drmemory.pl -- java HelloWorld What is the expected output? What do you see instead? "HELLO WORLD!" is expected. Got a fatal error by JVM instead. What version of the product are you using? On what operating system? DrMemory: DrMemory-Linux-1.4.4-2
Java: java version 1.6.0_22 OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.01) OpenJDK Client VM (build 20.0-b11, mixed mode, sharing)
Linux:
2.6.38-11-generic #50-Ubuntu
Ubuntu 11.04
VirtualBox: Version 4.1.2 r73507 Windows (as host of VB): Windows XP Professional Version 2002 Service Pack 3 Please provide any additional information below. See logs.
Attachment: fork.log global.2190.log results.txt results-summary.txt suppress.txt error_log.txt
Original issue: http://code.google.com/p/drmemory/issues/detail?id=626
From saxonophon on October 17, 2011 08:12:05
I forgot the HelloWorld sourcecode.
Attachment: my_java.java
From [email protected] on October 20, 2011 11:23:21
I can repro on my slightly-different-version OpenJDK jvm
plain DR seems to work so this is specific to DrMem
debug DrMem: ~~1533~~ ASSERT FAILURE (thread 1533): /home/bruening/drmemory/git/src/drmemory/alloc_drmem.c:2035: !dr_memory_is_dr_internal(addr) && !dr_memory_is_in_client(addr) (app is using tool's memory: please report this!)
Status: Accepted
Owner: [email protected]
From [email protected] on November 01, 2011 11:04:52
I can reproduce on my own machine. From the log, it looks like the memory is from libdynamorio.so
...
module load event: "libdynamorio.so.3.0" 0xf7439000-0xf7766000 /home/zhaoqin/Workspace/DrMemory/build/dynamorio/lib32/debug/libdynamorio.so.3.0
...
WARNING: unknown region 0xf7439000-0xf765e000: marking as defined FATAL ERROR: ASSERT FAILURE (thread 21950): /home/zhaoqin/Workspace/DrMemory/src/drmemory/alloc_drmem.c:2043: !dr_memory_is_dr_internal(addr) && !dr_memory_is_in_client(addr) (app is using tool's memory: please report this!)
From [email protected] on November 01, 2011 11:19:53
#0 syscall_0args () at /home/zhaoqin/Workspace/DrMemory/src/dynamorio/core/x86/x86.asm:1071 #1 0xf7625000 in dump_callstack (pc=0x0, ebp=0x1b8d1816 "", outfile=1, dump_xml=40) at /home/zhaoqin/Workspace/DrMemory/src/dynamorio/core/x86/disassemble.c:1453 #2 0xf7648db9 in os_read (f=0, buf=0x1b8d1816, count=1) at /home/zhaoqin/Workspace/DrMemory/src/dynamorio/core/linux/os.c:3300 #3 0xf763df08 in dr_read_file (f=0, buf=0x1b8d1816, count=1) at /home/zhaoqin/Workspace/DrMemory/src/dynamorio/core/x86/instrument.c:2953 #4 0xf7188af9 in wait_for_user (message=0x1b8d1838 "Dr. Memory is paused at an assert in pid=25170") at /home/zhaoqin/Workspace/DrMemory/src/common/utils.c:110 #5 0xf7188b4d in drmemory_abort () at /home/zhaoqin/Workspace/DrMemory/src/common/utils.c:124 #6 0xf716068d in check_unaddressable_exceptions (write=0 '\000', loc=0x1b8d1b78, addr=0xf740003c "", sz=4, addr_on_stack=0 '\000', mc=0x1b8d1d60) at /home/zhaoqin/Workspace/DrMemory/src/drmemory/alloc_drmem.c:2041 #7 0xf70d4187 in handle_mem_ref (flags=8, loc=0x1b8d1b78, addr=0xf740003c "", sz=4, mc=0x1b8d1d60, shadow_vals=0x1b8d1b94) at /home/zhaoqin/Workspace/DrMemory/src/drmemory/readwrite.c:2972 #8 0xf70d2ba5 in check_mem_opnd (opc=55, flags=8, loc=0x1b8d1b78, opnd=..., sz=4, mc=0x1b8d1d60, shadow_vals=0x1b8d1b94) at /home/zhaoqin/Workspace/DrMemory/src/drmemory/readwrite.c:2878 #9 0xf70ca1dc in slow_path_with_mc (drcontext=0x1b6f1500, pc=0xf698649b "\213P\b\203\070\001u\360\213M\360\001ʋM\354\205\311t\005\071U\354v\003\211U\354\213M\020\213\t\211M\344\071\312w\320\003P\024\071\321s\311F\203\300 \306E\353\001\071\367uŀ}", <incomplete sequence \353>, decode_pc=0xf698649b "\213P\b\203\070\001u\360\213M\360\001ʋM\354\205\311t\005\071U\354v\003\211U\354\213M\020\213\t\211M\344\071\312w\320\003P\024\071\321s\311F\203\300 \306E\353\001\071\367uŀ}", <incomplete sequence \353>, mc=0x1b8d1d60) at /home/zhaoqin/Workspace/DrMemory/src/drmemory/readwrite.c:1985 #10 0xf70cb8f5 in slow_path ( pc=0xf698649b "\213P\b\203\070\001u\360\213M\360\001ʋM\354\205\311t\005\071U\354v\003\211U\354\213M\020\213\t\211M\344\071\312w\320\003P\024\071\321s\311F\203\300 \306E\353\001\071\367uŀ}", <incomplete sequence \353>, decode_pc=0xf698649b "\213P\b\203\070\001u\360\213M\360\001ʋM\354\205\311t\005\071U\354v\003\211U\354\213M\020\213\t\211M\344\071\312w\320\003P\024\071\321s\311F\203\300 \306E\353\001\071\367uŀ}", <incomplete sequence \353>) at /home/zhaoqin/Workspace/DrMemory/src/drmemory/readwrite.c:2168 #11 0x1b5cc07e in ?? () #12 0xf73726de in dl_iterate_phdr () from /usr/grte/v2/lib/libc.so.6 ...
From [email protected] on November 01, 2011 11:19:54
xref PR 352425: [linux] transparency: hide from dl_iterate_phdr()
From [email protected] on December 03, 2012 18:47:13
In the meantime, we have actually implemented early injection in DR. We can easily hide from dl_iterate_phdr() by using it. Dr. Memory will probably need changes in order to work with early injection on Linux, though.
Assigning this to myself since this is related to sorting out our frontends.
Owner: [email protected]
From [email protected] on December 04, 2012 16:52:38
Adding -early to drmemory.pl's invocation of drrun doesn't Just Work. I hit assertions about invalid heap state. We'll need changes on the drmemory side to support it.
From [email protected] on December 04, 2012 18:52:20
this is not surprising. there is a bunch of setup for the state of the address space at startup and it looks rather different for early vs late.
did we try just relaxing this assert? does it run fine if the assert is ignored (-ignore_asserts)?
From [email protected] on February 11, 2013 12:52:18
-ignore_asserts makes it past the assertion, but we generate a bad OP_mov_ld variant somewhere in VM_Version::get_processor_features(). The app bb should be:
(gdb) x/50i start 0xf6a81ced <_ZN10VM_Version22get_processor_featuresEv+2557>: movzwl 0x46aa2c(%ebx),%edi 0xf6a81cf4 <_ZN10VM_Version22get_processor_featuresEv+2564>: movzwl 0x46aa3c(%ebx),%eax 0xf6a81cfb <_ZN10VM_Version22get_processor_featuresEv+2571>: xor %edx,%edx 0xf6a81cfd <_ZN10VM_Version22get_processor_featuresEv+2573>: div %di 0xf6a81d00 <_ZN10VM_Version22get_processor_featuresEv+2576>: movzwl %ax,%eax 0xf6a81d03 <_ZN10VM_Version22get_processor_featuresEv+2579>: jmp 0xf6a8158e <_ZN10VM_Version22get_processor_featuresEv+670>
We seem to generate bad instrumentation on div %di. DR's disas of this instr: 0xf6937cfd 66 f7 f7 data16 div %di %dx %ax -> %dx %ax
From [email protected] on February 21, 2013 08:10:40
Idea: relax the assert to be OK with the app reading our phdrs, but not our data or code.
This happened to me then I work on libminecraft as well. I tried to enable adaptive optimization for LWJGL and the JVM using DynamoRIO, and it displayed extremely bad startup performance + crashed randomly for nearly no reason at all.
