derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 05:24:38

What version of DynamoRIO are you using? I am using DR 4.1 custom build. What operating system version are you running on? I am running Ubuntu 12.04 x86_64. What application are you running? bodytrack benchmark from PARSEC suite. Is your application 32-bit or 64-bit? 64bit application. How are you running the application under DynamoRIO? I am using an umbra client and drrun to run application. What happens when you run without any client? It works.

The following code in the client-share-detect which is part of umbra memory shadowing tool works fine with DR 3 but it does not work with DR 4. It causes "Segmentation fault (core dumped)" when run with DR 4.

static void instrument_update(void drcontext, umbra_info_t umbra_info, mem_ref_t ref, instrlist_t ilist, instr_t where) { instr_t instr, label; opnd_t opnd1, opnd2; reg_id_t reg = umbra_info->steal_regs[0]; client_tls_data_t tls_data;

tls_data = umbra_info->client_tls_data;

label = INSTR_CREATE_label(drcontext);
instrlist_meta_preinsert(ilist, where, label);

/* test [&#37;reg].tid_map, tid_map*/
opnd1 = opnd_create_base_disp(reg, DR_REG_NULL, 0,
        offsetof(shadow_data_t, tid_map),
        OPSZ_4);
opnd2 = OPND_CREATE_INT32(tls_data->tid_map);
instr = INSTR_CREATE_test(drcontext, opnd1, opnd2);
instrlist_meta_preinsert(ilist, label, instr);
instr_set_ok_to_mangle(instr, true);
instr_set_translation(instr, ref->pc);
instr_set_meta_may_fault(instr, true);

/* jnz label */
opnd1 = opnd_create_instr(label);
instr = INSTR_CREATE_jcc(drcontext, OP_jnz, opnd1);
instrlist_meta_preinsert(ilist, label, instr);
/* racy or */
opnd1 = opnd_create_base_disp(reg, DR_REG_NULL, 0,
        offsetof(shadow_data_t, tid_map),
        OPSZ_4);
opnd2 = OPND_CREATE_INT32(tls_data->tid_map);
instr = INSTR_CREATE_or(drcontext, opnd1, opnd2);
instrlist_meta_preinsert(ilist, label, instr);
instr_set_ok_to_mangle(instr, true);
instr_set_translation(instr, ref->pc);
instr_set_meta_may_fault(instr, true);

}

How can I run this code with DR 4?

Thanks, Etem

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1259

derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 02:38:41

Actually, the client works fine for small size applications and it crashes for large size multi-threaded applications. -Etem

derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 04:17:02

Here is the output of the same case when I use debug flag.

etem@etem-Dell-System-XPS-L502X:~/TOOLS$ /home/etem/TOOLS/DynamoRIO-Linux-4.1.0-8/bin64/drrun -debug -ops " -thread_private" -client /home/etem/TOOLS/umbra/build/bin/libsharedetect.so 0 "" /home/etem/DATA/parsec-2.1/bin/../pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inputs/sequenceB_1 4 1 5 1 0 8 <Starting application /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack (12312)> <Paste into GDB to debug DynamoRIO clients: set confirm off add-symbol-file '/home/etem/TOOLS/umbra/build/bin/libsharedetect.so' 0x0000000072005a70 add-symbol-file '/home/etem/TOOLS/DynamoRIO-Linux-4.1.0-8/ext/lib64/debug/libdrmgr.so' 0x0000000073002370 add-symbol-file '/home/etem/TOOLS/DynamoRIO-Linux-4.1.0-8/ext/lib64/debug/libdrx.so' 0x0000000077001180 add-symbol-file '/lib/x86_64-linux-gnu/libc.so.6' 0x00007fa56ca50fa0 add-symbol-file '/lib64/ld-linux-x86-64.so.2' 0x00007fa56c80daf0

<Initial options = -client_lib '/home/etem/TOOLS/umbra/build/bin/libsharedetect.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_shared_bbs -no_shared_traces -thread_private -no_atomic_inlined_linking -no_shared_trace_ibl_routine -no_finite_bb_cache -no_finite_trace_cache -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct > PARSEC Benchmark Suite Version 2.1 Threading with Posix Threads Number of threads : 8 <Application /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack (12312). Application exception at PC 0x00007fffb95fecd4.
Signal 11 delivered to application as default action. Callstack: 0x00007fffb95fecd4

<Stopping application /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack (12312)> <Application /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack (12312). Internal Error Internal DynamoRIO Error: /work/dr/git/src/core/unix/signal.c:1739 i == 0 (Error occurred @5408 frags) version 4.1.0, build 8 -client_lib '/home/etem/TOOLS/umbra/build/bin/libsharedetect.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_shared_bbs -no_shared_traces -thread_private -no_atomic_inlined_linking -no_shared_trace_ibl_routine -no_finite_bb_cache -no_finite_trace_cache -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct 0x000000004f0e9e00 0x0000000071111d79 0x000000004f0e9f60 0x00000000712e042d 0x000000004f0e9fa0 0x00000000712c9707 0x000000004f0e9fd0 0x000000007108cd47 0x000000004f0ea030 0x000000007108d528 0x000000004f0ea0c0 0x00000000711fd8a9 0x000000004f0ea3f0 0x00000000711fe7ac 0x000000004f0ea4c0 0x000000007108aec2 0x000000004f0ea4f0 0x000000007108aff4 0x000000004f0ea520 0x000000007108b19e 0x000000004f0ea550 0x000000007129892c 0x000000004f0ea568 0x000000004f030900 /home/etem/TOOLS/umbra/build/bin/libsharedetect.so=0x0000000072000000 /home/etem/TOOLS/DynamoRIO-Linux-4.1.0-8/ext/lib64/debug/libdrmgr.so=0x0000000073000000 /home/etem/TOOLS/DynamoRIO-Linux-4.1.0-8/ext/lib64/debug/libdrx.so=0x0000000077000000 /lib/x86_64-linux-gnu/libc.so.6=0x00007fa56ca32000 /lib64/ld-linux-x86-64.so.2=0x00007fa56c80d000>

derekbruening commented 10 years ago

From bruen...@google.com on August 30, 2013 07:54:12

That code looks incorrect, regardless of the DR version used:

instrlist_meta_preinsert(ilist, label, instr);
instr_set_ok_to_mangle(instr, true);    \<---- should be false
instr_set_translation(instr, ref->pc);
instr_set_meta_may_fault(instr, true);  \<---- this is deprecated

IIUC, that's supposed to be a meta instruction, yet it's marked as an app instruction. Thus on a fault DR will deliver the signal to the app, as we see it doing. Basically DR did what the client asked it to do, so there's no DR bug there, but a client bug.

The assert in signal.c "i == 0" is a DR issue. Could you file a separate issue on that assert? I wonder if you could get the actual value of i so we can see why the sigaltstack restore failed?

Status: NotABug

derekbruening commented 10 years ago

From zhao...@google.com on August 30, 2013 08:21:26

That's the code I wrote long time ago, does not remember the details.

The instructions inserted touch shadow memory, which may cause fault (on purpose), so we set instr_set_meta_may_fault(instr, true) so that we can handle the fault. It is depreciated, can be removed directly.

instr_set_ok_to_mangle(instr, true); does not look correct, but the implementation of instr_set_meta_may_fault will set it back to false, so it should not deliver the signal to app.

void instr_set_meta_may_fault(instr_t instr, bool val) { / no longer using a special flag (issue #496) */ instr_set_ok_to_mangle(instr, false); CLIENT_ASSERT(instr_get_translation(instr) != NULL, "meta_may_fault instr must have translation"); }

It is not clear to me which instruction caused the fault. Can you show the code fragment and the instruction that causes the fault.

You can also turn opt_ems64 off (assign it to false in the code ( https://github.com/zhaoqin/Umbra/blob/master/core/umbra.c) ), and Umbra will not cause any fault, and you can see if it works.

derekbruening commented 10 years ago

From zhao...@google.com on August 30, 2013 08:21:42

Status: NeedInfo

derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 11:10:53

I've checked umbra.c and opt_ems64 is set to false. I modified the /unix/signal.c and found the actual value of i. The actual value of i is -1 and the assert fails.

I also modified the client code as you said. I removed "instr_set_meta_may_fault(instr, true);" part. I fixed the second line as "instr_set_ok_to_mangle(instr, as);"

Any ideas? Thanks, Etem

derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 11:24:52

When I run the same client on other application. I got a different error given below.

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun -debug -ops " -thread_private" -client /home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so 0 "" /home/etem/Desktop/main_single <Starting application /home/etem/Desktop/main_single (27070)> <Paste into GDB to debug DynamoRIO clients: set confirm off add-symbol-file '/home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so' 0x0000000072005a20 add-symbol-file '/home/etem/TOOLS/dynamorio-debug/build/ext/lib64/debug/libdrmgr.so' 0x0000000073002230 add-symbol-file '/home/etem/TOOLS/dynamorio-debug/build/ext/lib64/debug/libdrx.so' 0x0000000077001100 add-symbol-file '/lib/x86_64-linux-gnu/libc.so.6' 0x00007fb7182a4fa0 add-symbol-file '/lib64/ld-linux-x86-64.so.2' 0x00007fb718060af0

<Initial options = -client_lib '/home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_shared_bbs -no_shared_traces -thread_private -no_atomic_inlined_linking -no_shared_trace_ibl_routine -no_finite_bb_cache -no_finite_trace_cache -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct > HELLO ETEM <Stopping application /home/etem/Desktop/main_single (27070)> <Application /home/etem/Desktop/main_single (27070) DynamoRIO usage error : memory leak detected> <Usage error: memory leak detected (/home/etem/TOOLS/dynamorio-debug/core/heap.c, line 2785) version 4.1.2253, custom build -client_lib '/home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -no_shared_bbs -no_shared_traces -thread_private -no_atomic_inlined_linking -no_shared_trace_ibl_routine -no_finite_bb_cache -no_finite_trace_cache -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2d 0x000000005017e530 0x000000007111b2b3 0x000000005017e590 0x00000000711abb92 0x000000005017e620 0x00000000711ace0b 0x000000005017e6b0 0x00000000711ad2f6 0x000000005017e6e0 0x0000000071095773 0x000000005017e740 0x00000000710958ea 0x000000005017e760 0x0000000071093528 0x000000005017e780 0x0000000071093886 0x000000005017e7b0 0x0000000071093a10 0x000000005017e7e0 0x00000000712a35c4 0x000000005017e7f8 0x000000005011d940>

-Etem

derekbruening commented 10 years ago

From etemden...@gmail.com on August 30, 2013 11:44:01

Here is the output when the log is enabled.

global log file fd=4000 DynamoRIO version 4.1.2253, custom build, (c) DynamoRIO developers Running: /home/etem/DATA/parsec-2.1/pkgs/apps/bodytrack/inst/amd64-linux.gcc.pre/bin/bodytrack DynamoRIO built with: -DINTERNAL -DDEBUG -DDRGUI_DEMO -DX64 -DLINUX -DUNIX -DCLIENT_INTERFACE -DAPP_EXPORTS -DKSTATS -DHAVE_FVISIBILITY -DDR_DO_NOT_DEFINE_uint -DDR_DO_NOT_DEFINE_ushort -DDR__Bool_EXISTS -DX86 -DASSEMBLE_WITH_GAS -DHAVE_PROC_MAPS -DHAVE_TLS -DHAVE_SIGALTSTACK -DUSE_VISIBILITY_ATTRIBUTES -DDYNAMORIO_IR_EXPORTS -DCUSTOM_TRACES -DCLIENT_SIDELINE -DDR_APP_EXPORTS -DDEBUG_MEMORY -DSTACK_GUARD_PAGE -DHEAP_ACCOUNTING -DDEADLOCK_AVOIDANCE -DSHARING_STUDY -DHASHTABLE_STATISTICS DynamoRIO built on: Aug 30 2013 21:03:49 DYNAMORIO_OPTIONS: -code_api -loglevel 10 -thread_private -client_lib "/home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so;0;" DynamoRIO's stack size: 56 Kb acquired lock 0x00000000715e32a0 memory_info_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/unix/os.c:302 rank=86, not valid dcontext, tid:27440, 1 time acquired lock 0x00000000715e32a0 memory_info_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/unix/os.c:302 rank=86 add_process_lock0 lock 0x00000000715e32a0: name=memory_info_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/unix/os.c:302 rank=86 owner=27440 owning_dc=0x0000000000000000 0x0 prev=0x0000000000000000 lock count_times_acquired= 1 0 0 0 0+2 memory_info_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/unix/os.c:302 acquired lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95, not valid dcontext, tid:27440, 4 time acquired lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95 released lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95, not valid dcontext, tid:27440 released lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95 get_memory_info_from_os: bytes read 4016/want 4103 acquired lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90, not valid dcontext, tid:27440, 3 time acquired lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90 released lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90, not valid dcontext, tid:27440 released lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90 acquired lock 0x00000000715e6a80 report_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:2028 rank=85, not valid dcontext, tid:27440, 1 time acquired lock 0x00000000715e6a80 report_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:2028 rank=85 add_process_lock0 lock 0x00000000715e6a80: name=report_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:2028 rank=85 owner=27440 owning_dc=0x0000000000000000 0x0 prev=0x0000000000000000 lock count_times_acquired= 1 0 0 0 0+2 report_buf_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:2028 acquired lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95, not valid dcontext, tid:27440, 5 time acquired lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95 released lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95, not valid dcontext, tid:27440 released lock 0x00000000715e6980 innermost_lock(mutex)@/home/etem/TOOLS/dynamorio-debug/core/utils.c:219 rank=95 acquired lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90, not valid dcontext, tid:27440, 4 time acquired lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90 released lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90, not valid dcontext, tid:27440 released lock 0x00000000715e6160 options_lock(readwrite)@/home/etem/TOOLS/dynamorio-debug/core/options.c:184 rank=90

derekbruening commented 10 years ago

From etemden...@gmail.com on August 31, 2013 03:13:00

When I do not include drmgr.h I get the error that I mentioned previously. This time I try to include drmgr.h and check what happens. I thinks it should solve order violation problem. Now, I get "<WARNING! symbol lookup error: libsharedetect.so undefined symbol DO_NOT_USE_bb_event_USE_drmgr_bb_events_instead>" "<ERROR: using undefined symbol!>" error. Here is the code that I tried.

DR_EXPORT void dr_init(client_idt id) { /* register all events / drmgr_init(); dr_register_exit_event(event_exit); dr_register_bb_event(event_bb); dr_register_trace_event(event_trace); dr_register_end_trace_event(event_end_trace); dr_register_delete_event(event_delete); drmgr_register_restore_state_event(event_restore_state); drmgr_register_thread_init_event(event_thread_init); drmgr_register_thread_exit_event(event_thread_exit); tls_idx = drmgr_register_tls_field(); DR_ASSERT(tls_idx != -1); dr_register_fork_init_event(event_fork_init); drmgr_register_module_load_event(event_module_load); drmgr_register_module_unload_event(event_module_unload); dr_register_filter_syscall_event(event_filter_syscall); drmgr_register_pre_syscall_event(event_pre_syscall); drmgr_register_post_syscall_event(event_post_syscall);

ifdef LINUX

drmgr_register_signal_event(event_signal);

else

drmgr_register_exception_event(event_exception);

endif /_ LINUX */

/* client-self init event */
event_init(id);

}

derekbruening commented 10 years ago

From etemden...@gmail.com on September 01, 2013 02:17:53

Next, instead of "dr_register_bb_event(event_bb)" in dr_client.c I use the following code for Dr 4.1

static dr_emit_flags_t event_bb_app2app(void drcontext, void tag, instrlist_t *bb, bool for_trace, bool translating) { return DR_EMIT_DEFAULT; }

static dr_emit_flags_t event_bb_analysis(void _drcontext, void tag, instrlist_t bb, bool for_trace, bool translating, OUT void *_user_data) { return DR_EMIT_DEFAULT; }

static dr_emit_flags_t event_bb_insert(void drcontext, void tag, instrlist_t bb, instr_t instr, bool for_trace, bool translating, void *user_data) { return event_bb(drcontext, tag, bb, for_trace, translating); }

DR_EXPORT void dr_init(client_id_t id) { drmgr_priority_t priority = { sizeof(priority), "umbra", NULL, NULL, 0}; .... if (!drmgr_register_thread_init_event(event_thread_init) || !drmgr_register_thread_exit_event(event_thread_exit) || !drmgr_register_bb_app2app_event(event_bb_app2app, &priority) || !drmgr_register_bb_instrumentation_event(event_bb_analysis, event_bb_insert, &priority)) { /* something is wrong: can't continue */ DR_ASSERT(false); return; } .... }

With the code I give above, an umbra reletad assert fails: ASSERT FAILURE: /home/etem/TOOLS/umbra-debug/core/cfg.c:254: (tag + length) == instr_get_app_pc(instr) (BB does not have a continuous code!)

Any ideas?

Thanks, Etem

derekbruening commented 10 years ago

From bruen...@google.com on September 01, 2013 06:39:36

Re: comment #8: everything ran correctly except there's a memory leak in the client. Your changes, or maybe the original Umbra code, has a memory leak.

Re: comment #9: pasting the top of the log file (likely truncated to avoid enormous posts like you tried to do), especially with newlines removed, is not helpful. It's not readable and it does not contain any error messages. You need to attach logfiles, or just paste the one or two lines with the error message.

Re: comment #10: there is no drmgr in the old Umbra. It's not clear why you're trying to add it. What ordering problem are you trying to solve? drmgr is only needed when there are multiple components to coordinate, or if using an Extension that uses drmgr.

Back to the original crash: Qin asked for information on the crash. Please attach a debugger and determine where it's crashing. See https://code.google.com/p/dynamorio/wiki/Debugging

derekbruening commented 10 years ago

From etemden...@gmail.com on September 01, 2013 09:48:29

OK, I undid the updates in umbra that I dif for porting it to DR4. Now, I am running the original umbra code which works fine on DR3. (There is no updates)

When I run with debug flag, I get the following output and I am attaching log files.

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun -debug -ops "-loglevel 3 -thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so 0 "" /home/etem/Desktop/main_multi

Thread 1 says Hello! Thread 2 says Hi! When I run without debug flag, I get the following output. etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio/build/bin64/drrun -ops "-thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/umbra/build/bin/libsharedetect.so 0 "" /home/etem/Desktop/main_multi Thread 1 says Hello! Thread 2 says Hi! Segmentation fault (core dumped) Are log files are enough to see crash point or should I attach the process? I am trying to attach the process after having the following message but I am getting the following error. (Note that "kernel.yama.ptrace_scope = 0" in 10-ptrace.conf) Attaching to process 7046 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. -Etem **Attachment:** [main_multi.6782.00000000.tar.gz](http://code.google.com/p/dynamorio/issues/detail?id=1259#hc13)

derekbruening commented 10 years ago

From etemden...@gmail.com on September 01, 2013 13:31:52

When I tried to the first technique given in "Dynamorio Debugging" page, I got the following error. (Note that I have permission to execute drrun)

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ gdb --args /bin/bash /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun -debug -ops "-thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client -- /home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so 0 "" /home/etem/Desktop/main_multi GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: < http://bugs.launchpad.net/gdb-linaro/>.. . Reading symbols from /bin/bash...(no debugging symbols found)...done. (gdb) run Starting program: /bin/bash /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun -debug -ops -thread_private\ -max_bb_instrs\ 512\ -no_finite_bb_cache\ -no_finite_trace_cache -client -- /home/etem/TOOLS/umbra-debug/build/bin/libsharedetect.so 0 '' /home/etem/Desktop/main_multi /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun: /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun: cannot execute binary file [Inferior 1 (process 3153) exited with code 0176]

derekbruening commented 10 years ago

From bruen...@google.com on September 01, 2013 18:11:17

Re: comment #13: we want to see the disassembly of the instructions around the crash point, and the register values. You'll need to address your lack of ptrace permissions (maybe this applies: http://askubuntu.com/questions/41629/after-upgrade-gdb-wont-attach-to-process ).

Re: comment #14: your command line is incorrect ("--" in wrong place).

Owner: zhao...@google.com
Labels: Component-DRTool

derekbruening commented 10 years ago

From etemden...@gmail.com on September 01, 2013 20:47:11

This is also not working.

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ gdb --args /bin/bash /home/etem/TOOLS/dynamorio/build/bin64/drrun -ops "-thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/umbra/build/bin/libsharedetect.so 0 "" -- /home/etem/Desktop/main_multi GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: < http://bugs.launchpad.net/gdb-linaro/>.. . Reading symbols from /bin/bash...(no debugging symbols found)...done. (gdb) run Starting program: /bin/bash /home/etem/TOOLS/dynamorio/build/bin64/drrun -ops -thread_private\ -max_bb_instrs\ 512\ -no_finite_bb_cache\ -no_finite_trace_cache -client /home/etem/TOOLS/umbra/build/bin/libsharedetect.so 0 '' -- /home/etem/Desktop/main_multi warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 /home/etem/TOOLS/dynamorio/build/bin64/drrun: /home/etem/TOOLS/dynamorio/build/bin64/drrun: cannot execute binary file [Inferior 1 (process 2539) exited with code 0176]

instructions and registers:

1: x/10i $pc => 0x4c993bc2: movabs %rax,%gs:0x0 0x4c993bcd: movabs $0x7132ef28,%rax 0x4c993bd7: jmpq 0x4c992d80 0x4c993bdc: nop 0x4c993bdd: nop 0x4c993bde: nop 0x4c993bdf: nop 0x4c993be0: nop 0x4c993be1: nop 0x4c993be2: nop rcx 0xffffffffffffffff -1 rdx 0x1da6 7590 rsi 0x0 0 rdi 0x7feb6fd439d0 140649170221520 rbp 0x0 0x0 rsp 0x7fff255825c0 0x7fff255825c0 r8 0x0 0 r9 0x7feb6f542700 140649161828096 r10 0x0 0 r11 0x246 582 r12 0x7feb6fd43d28 140649170222376 r13 0x7feb71211700 140649192036096 r14 0x0 0 r15 0x0 0 rip 0x4c993bc2 0x4c993bc2 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x6b 107 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 0 (raw 0x00000000000000000000) st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x0 0

(gdb) nexti 0x000000004c993bc2 in ?? () 1: x/10i $pc => 0x4c993bc2: movabs %rax,%gs:0x0 0x4c993bcd: movabs $0x7132ef28,%rax 0x4c993bd7: jmpq 0x4c992d80 0x4c993bdc: nop 0x4c993bdd: nop 0x4c993bde: nop 0x4c993bdf: nop 0x4c993be0: nop 0x4c993be1: nop 0x4c993be2: nop rax 0xfffffffffffffe00 -512 rbx 0x7feb6fd43700 140649170220800 rcx 0xffffffffffffffff -1 rdx 0x1da6 7590 rsi 0x0 0 rdi 0x7feb6fd439d0 140649170221520 rbp 0x0 0x0 rsp 0x7fff255825c0 0x7fff255825c0 r8 0x0 0 r9 0x7feb6f542700 140649161828096 r10 0x0 0 r11 0x346 838 r12 0x7feb6fd43d28 140649170222376 r13 0x7feb71211700 140649192036096 r14 0x0 0 r15 0x0 0 rip 0x4c993bc2 0x4c993bc2 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x6b 107 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 0 (raw 0x00000000000000000000) st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x0 0

(gdb) nexti

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7feb6fd43700 (LWP 7590)] 0x000000004d956bf9 in ?? () 1: x/10i $pc => 0x4d956bf9: testl $0x2,0x0(%rbp) 0x4d956c00: jne 0x4d956c0d 0x4d956c06: orl $0x2,0x0(%rbp) 0x4d956c0d: mov -0xa0bf64(%rip),% r15 # 0x4cf4acb0 0x4d956c14: add $0x7f,%al 0x4d956c16: sahf
0x4d956c17: mov 0xffffffffff5ff0a8,%rax 0x4d956c1f: mov %rsp,%rbp 0x4d956c22: je 0x4d942441 0x4d956c28: jmpq 0x4d942486

rax 0x4600 17920 rbx 0x0 0 rcx 0x696c0031 1768685617 rdx 0x0 0 rsi 0x0 0 rdi 0x0 0 rbp 0x15dfff5ff080 0x15dfff5ff080 rsp 0x7feb6fd42530 0x7feb6fd42530 r8 0xfefefefefefefeff -72340172838076673 r9 0x5 5 r10 0x10 16 r11 0x1000000004 68719476740 r12 0x24 36 r13 0x3 3 r14 0x7feb71234040 140649192177728 r15 0x7feb71209d42 140649192004930 rip 0x4d956bf9 0x4d956bf9 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x6b 107 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 0 (raw 0x00000000000000000000) st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x0 0

(gdb) nexti master_signal_handler () at /home/etem/TOOLS/dynamorio-debug/core/x86/x86.asm:1295 1295 #else 1: x/10i $pc => 0x712a3707 : mov %rsp,%rcx 0x712a370a <master_signal_handler+3>: jmpq 0x712f6370 0x712a370f : sub $0x8,%rsi 0x712a3713 <dynamorio_clone+4>: mov % r9 ,(%rsi) 0x712a3716 <dynamorio_clone+7>: mov %rcx,% r10 0x712a3719 <dynamorio_clone+10>: mov $0x38,%rax 0x712a3720 <dynamorio_clone+17>: syscall 0x712a3722 <dynamorio_clone+19>: cmp $0x0,%rax 0x712a3726 <dynamorio_clone+23>: jne 0x712a3732 0x712a3728 <dynamorio_clone+25>: mov %eax,%gs ...

derekbruening commented 10 years ago

From etemden...@gmail.com on September 02, 2013 10:27:19

backtrace:

0x000000004f563bc2 in ?? () (gdb) bt

0 0x000000004f563bc2 in ?? ()

1 0x00007fff0721a100 in ?? ()

2 0x00007fa115a09235 in ?? () from /lib64/ld-linux-x86-64.so.2

3 0x00000000004007df in main () at ../hello.c:43

(gdb) nexti 0x000000004f563bc2 in ?? () (gdb) bt

0 0x000000004f563bc2 in ?? ()

1 0x00007fff0721a100 in ?? ()

2 0x00007fa115a09235 in ?? () from /lib64/ld-linux-x86-64.so.2

3 0x00000000004007df in main () at ../hello.c:43

(gdb) nexti

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa114726700 (LWP 2988)] 0x0000000050556bf9 in ?? () (gdb) bt

0 0x0000000050556bf9 in ?? ()

1 0x00007fa1147255a0 in ?? ()

2 0x00007fa1152ff3f8 in get_nprocs () from /lib/x86_64-linux-gnu/libc.so.6

Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Any ideas after instructions and bt info?

Thanks, Etem

derekbruening commented 10 years ago

From etemden...@gmail.com on September 02, 2013 13:19:57

I was using the umbra that I have ported to DR 3. Today, I also tried the umbra that is ported by quin. It results in the following error.

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio/build/bin64/drrun -ops "-thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/umbra-master/build/bin/libsharedetect.so 0 "" /home/etem/workspace/hello/Debug/hello pid = 4626 Thread 1 says Hello! Thread 2 says Hi! Error CASSERT FAILURE: /home/etem/TOOLS/umbra-master/core/shadow.c:1599: cache != ((void *)0) ()

I will compare two versions but anyway, we have two different versions of umbra and both work fine with DR 3 on Ubuntu 11.*.

derekbruening commented 10 years ago

From etemden...@gmail.com on September 03, 2013 00:33:42

From another point of view, my porting and DR 4.1 work fine on Ubuntu 11.10 but they do not work on Ubuntu 12.04. Is the problem related with OS I used?

I also compared my and qin's porting. There are some differences in core codes. For example, qin has the following updates.

if(reg != REG_ESP)
if(reg != DR_REG_XSP)
if (reg == REG_ECX && instr_is_rep_ins(instr))
if (reg == DR_REG_XCX && instr_is_rep_ins(instr))
if (opnd_uses_reg(mem->ref->opnd, REG_RSP))
if (opnd_uses_reg(mem->ref->opnd, DR_REG_XSP)) I have the followings.
if(reg != REG_ESP)
if(reg != DR_REG_ESP)
if (reg == REG_ECX && instr_is_rep_ins(instr))
if (reg == DR_REG_ECX && instr_is_rep_ins(instr))
if (opnd_uses_reg(mem->ref->opnd, REG_RSP))
if (opnd_uses_reg(mem->ref->opnd, DR_REG_RSP))

It is clear that there are some differences in codes. However, both umbra works fine on Ubuntu 11.10 but not on 12.04.

derekbruening commented 10 years ago

From qin.zhao@gmail.com on September 03, 2013 08:03:43

c#20: the DRREG* should not matter c#18: different OS or compiler may cause different memory layouts that Umbra fail to handle.

c#13: I checked the log file, the segfault happens in instrumented code for 0x00007fffa0dc6cd4: 48 8b 04 25 a8 f0 5f ff mov 0xff5ff0a8 -> %rax The instrumentation are: +123 m4 @0x00000000475d84b8 48 bd 80 f0 5f ff 1d mov $0x00001b1dff5ff080 -> %rbp 1b 00 00 +133 m4 @0x00000000475d6b40 f7 45 00 02 00 00 00 test (%rbp) $0x00000002 +140 m4 @0x00000000475d8808 0f 85 fa ff ff ff jnz @0x00000000475d74f8 +146 m4 @0x00000000475d72a8 81 4d 00 02 00 00 00 or $0x00000002 (%rbp) -> (%rbp)

questions to be answered:

what's the lib has 0x00007fffa0dc6cd4
what's the address of 0xff5ff0a8, the address is from app/lib and looks strange
did Umbra handle static address 0xff5ff0a8 correctly? It looks to me it is the 0xff5ff0a8 causing the problem. Better to know how this memory is being allocated.

derekbruening commented 10 years ago

From qin.zhao@gmail.com on September 03, 2013 08:38:19

From the log file: 0x0000000000400000-0x0000000000401000 ---- ELF SO main_multi 0x0000000071000000-0x00000000713b3000 ---- ELF SO libdynamorio.so.4.1 0x0000000072000000-0x000000007201a000 ---- ELF SO libsharedetect.so 0x00007f51b3717000-0x00007f51b3812000 ---- ELF SO libm.so.6 0x00007f51b3a13000-0x00007f51b3a15000 ---- ELF SO libdl.so.2 0x00007f51b3c17000-0x00007f51b3dcc000 ---- ELF SO libc.so.6 0x00007f51b3fd6000-0x00007f51b3fee000 ---- ELF SO libpthread.so.0 0x00007f51b41f3000-0x00007f51b41f6000 ---- ELF SO libdrpreload.so 0x00007f51b43fe000-0x00007f51b4420000 ---- ELF SO ld-linux-x86-64.so.2 0x00007fffa0dc6000-0x00007fffa0dc8000 ---- Private 0xffffffffff600000-0xffffffffff601000 ---- Private

derekbruening commented 10 years ago

From etemden...@gmail.com on September 03, 2013 08:57:25

After comparing umbra core codes, I also compared my and qin's clients. There is a difference in "ref_is_interested" function and "num_steal_regs".

MY CODE: static bool ref_is_interested(umbra_info_t info, mem_ref_t ref) { if (opnd_is_far_base_disp(ref->opnd)) return false; return true; }

client->num_steal_regs = 2;

QIN' CODE: static bool ref_is_interested(umbra_info_t info, mem_ref_t ref) { if (opnd_is_far_base_disp(ref->opnd)) return false; if (opnd_uses_reg(ref->opnd, DR_REG_XSP)) return false; if (ref->opcode == OP_leave || ref->opcode == OP_enter) return false; return true; }

client->num_steal_regs = 1;

When I run my client code, I get segmentation fault as I mentioned. When I run qin's code, I get the following error: Error ^CASSERT FAILURE: /home/etem/TOOLS/umbra-debug/core/shadow.c:1384: cache != ((void *)0) ()

derekbruening commented 10 years ago

From qin.zhao@gmail.com on September 03, 2013 09:20:28

It is hard to tell which memory region 0x00007fffa0dc6000 is, might be [vdso]. But on my machine, the same offset in [vdso] does not have the same code.

etemdeniz2, can you provide a minimal test case so I can try to reproduce it on my machine. Meanwhile, can you keeps investigating as I may not be able to reproduce it.

derekbruening commented 10 years ago

From etemden...@gmail.com on September 03, 2013 09:30:30

I am attaching my test code, executable. I use the following command while compiling: gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"hello.d" -MT"hello.d" -o "hello.o" "../hello.c"

My running command and output: etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio/build/bin64/drrun -ops "-thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/umbra/build/bin/libsharedetect.so 0 "" /home/etem/workspace/hello/Debug/hello pid = 5211 Thread 1 says Hello! Thread 2 says Hi! Segmentation fault (core dumped)

Actually, I don't know what I should do the answer your questions? Can you please help me about the steps?

Note that your client does not result in segmentation fault. It results in an assert fail in your code codes: ASSERT FAILURE: /home/etem/TOOLS/umbra-debug/core/shadow.c:1384: cache != ((void *)0) () Maybe, my update in your client code causes segmentation fault.

Attachment: hello hello.c

derekbruening commented 10 years ago

From etemden...@gmail.com on September 03, 2013 09:44:02

I am also attaching log files for hello application I attached previously. Here is the output of debug run:

etem@etem-Dell-System-XPS-L502X:~/TOOLS/temp$ /home/etem/TOOLS/dynamorio-debug/build/bin64/drrun -debug -ops "-loglevel 3 -thread_private -max_bb_instrs 512 -no_finite_bb_cache -no_finite_trace_cache" -client /home/etem/TOOLS/my-umbra-debug/build/bin/libsharedetect.so 0 "" /home/etem/workspace/hello/Debug/hello

pid = 8409 Thread 1 says Hello! Thread 2 says Hi! **Attachment:** [hello.8409.00000000.tar.gz](http://code.google.com/p/dynamorio/issues/detail?id=1259#hc26)

derekbruening commented 10 years ago

From etemden...@gmail.com on September 04, 2013 13:59:25

I also ran DynamoRIO-Linux-3.2.0-3 and Umbra on Ubuntu 12.04. The client works/completes without any fault and assert fail but it does not preduce correct output. Any process about running DR 4 + Umbra on Ubuntu 12?

Thanks, Etem

derekbruening commented 10 years ago

From etemden...@gmail.com on September 06, 2013 06:54:46

When I search "0x00007fffa0dc6000" and 0x00007fffa0dc8000" adresses on the web, I connot find any results. However, for "0xffffffffff600000" and "0xffffffffff601000" adresses, there exists topics about Stack Smashing/problems on Ubuntu 12.* x86_64:

https://www.soldierx.com/tutorials/Stack-Smashing-Modern-Linux-System Info about adresses: 7fff32938000-7fff32939000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

I think, as you said this a OS-related problem. Any ideas about solving this problem?

derekbruening commented 10 years ago

From bruen...@google.com on September 06, 2013 07:02:31

If you could try to solve Qin's questions in c#21:

What is at 0xff5ff0a8 (address referenced by vso+0xcd4)? How is it allocated? Did Umbra miss the allocation?
Does gdb give a name for the routine at vdso+0xcd4?

derekbruening commented 10 years ago

From etemden...@gmail.com on September 06, 2013 12:46:16

I haven't much experience on gdb. So I do not know how I can answer the questions. Can you please help me about the steps that I should apply? After attaching the process, what should I do?

I think, Qin will try to create the same error on his machine. Maybe, it can be a better idea. We have another x86 machine (and Ubuntu 12.04) and we have the same problem. What I mean it that one can easily runs DR+umbra on Ubuntu 12.04 and triggers the same error. I can also share a remote connection with you and maybe you can connect and do debug on our remote machine.

Anyway, I cannot run my tool which uses DR and umbra on Ubuntu 12.04. I am running out of time and we are considering to use PIN instead of DR. But I love DR and umbra. We have used then and we have already cited your papers. I hope we can solve the problem and continue using DR.

derekbruening commented 10 years ago

From zhao...@google.com on September 06, 2013 14:29:13

looks like a bug in DR: original code: (gdb) x/10i 0x7fffac9ffa80 0x7fffac9ffa80 : push %rbp 0x7fffac9ffa81 <time+1>: test %rdi,%rdi 0x7fffac9ffa84 <time+4>: mov 0xffffffffff5ff088,%rax

In DR: +0 L3 55 push %rbp %rsp -> %rsp 0xfffffff8(%rsp) +1 L3 48 85 ff test %rdi %rdi +4 L3 48 8b 04 25 88 f0 5f ff mov 0xff5ff088 -> %rax It looks like DR get the wrong opnd for "mov 0xffffffffff5ff088,%rax", it should be 0xffffffffff5ff088, but DR got 0xff5ff088.

derekbruening commented 10 years ago

From zhao...@google.com on September 06, 2013 15:22:55

(gdb) p _di $18 = {opcode = 55, prefixes = 32, seg_override = 0 '\000', modrm = 4 '\004', mod = 0 '\000', reg = 0 '\000', rm = 4 '\004', has_sib = true, scale = 0 '\000', index = 4 '\004', base = 5 '\005', has_disp = true, disp = -10489720, size_immed = 140 '\214', size_immed2 = 140 '\214', immed_pc_relativize = true, immed_subtract_length = false, immed_pc_rel_offs = true, immed_shift = 32767, immed = 104, immed2 = 14164581632, startpc = 0x7fff427dfa84 "H\213\004%\210\360\377H\211\345t\003H\211\a]Ã\220\220\220\220\220\220\220\220\220U\203<%\020\360\377\001H\211\345t\271{", final_pc = 0x4ce21000 "@\020\342L", len = 8, dispabs = 0x7fff427dfa88 "\210\360\377H\211\345t\003H\211\a]Ã\220\220\220\220\220\220\220\220\220U\203<%\020\360\377\001H\211\345t\271{", x86_mode = false, origpc = 0x7fff427dfa84 "H\213\004%\210\360\377H\211\345t\003H\211\a]Ã\220\220\220\220\220\220\220\220\220U\203<%\020\360\377\001H\211\345t\271{", data_prefix = false, rep_prefix = false, repne_prefix = false, vex_vvvv = 76 'L', vex_encoded = false, cur_note = 35639418112, has_instr_opnds = 104}

(gdb) x/10bx 0x7fff427dfa84 0x7fff427dfa84 <time+4>: 0x48 0x8b 0x04 0x25 0x88 0xf0 0x5f 0xff 0x7fff427dfa8c <time+12>: 0x48 0x89 (gdb) p/x di->disp $20 = 0xff5ff088 (gdb) p di->has_disp $21 = true

the disp is an int. It looks like DR did not sig-extend the disp

derekbruening commented 10 years ago

From etemden...@gmail.com on September 07, 2013 01:15:07

Thank you. As you said DR uses 32bit opnd but it a 64bit opnd and DR does not sig-extend the disp. I also want to learn the next step. Do you fix the bug in DR and then release a new version?

Thanks again, Etem

derekbruening commented 10 years ago

From qin.zhao@gmail.com on September 07, 2013 09:03:11

There might not be an easy fix on DR side. Before we have the official fix, you can change Umbra to special handle this case, i.e., do the sign extension at: preinsert_calculate_shd_addr: addr = opnd_get_addr(mem->ref->opnd);( https://github.com/zhaoqin/Umbra/blob/master/core/instrument.c )

derekbruening commented 10 years ago

From etemden...@gmail.com on September 07, 2013 12:43:50

I added the following code block to preinsert_calculate_shd_addr/instrument.c. ... void addr; void shd_addr[MAX_NUM_SHADOWS]; addr = opnd_get_addr(mem->ref->opnd); // sign-extend int sign = (long long) addr >> 32; if (sign == 0) { // 32bit int sign = (long long) addr >> 31; if (sign == 1) { addr = 0xFFFFFFFF00000000LL | (long long) addr; } } // end ...

This is not the final version but works and extends the sign bit of a 32bit address to 64bit address as we want. However, I still get the same error/segfault.

Is there a problem in the code I added? Note that I have this code insertion in my machine and the remote machine that you connect has the your original code.

derekbruening commented 10 years ago

From zhao...@google.com on September 07, 2013 20:56:54

I would just using something like below: addr = (ptr_int_t)(int)addr;

I applied a patch on your machine, and see another problem: The instruction is: 0x7fff677ffa84 <time+4>: mov 0xffffffffff5ff088,%rax However, the memory map shows 0x7fff6777f000 0x7fff677a0000 0x21000 0x0 [stack] 0x7fff677ff000 0x7fff67800000 0x1000 0x0 [vdso] 0xffffffffff600000 0xffffffffff601000 0x1000 0x0 [vsyscall] It looks like the app referencing non-allocated memory. It is actually an optimization to get time without going to through kernel.

The memory is accessible, but now shown in the process memory map, so umbra does not know about it and thus no shadow memory allocated for it. So even we get the address correct, there still be access violation when accessing the shadow memory. That's a special memory, I would suggest handle it specially. That memory can only be written by the kernel and read by the user code, so for shared memory detection client, I would just ignore any memory reference to there.

derekbruening commented 10 years ago

From etemden...@gmail.com on September 08, 2013 07:43:07

I applied your patch to my code and I also modified the client as given below.

static bool ref_is_interested(umbra_info_t info, mem_ref_t ref) { void *addr;

if (opnd_is_far_base_disp(ref->opnd))
    return false;

if ((opnd_is_rel_addr(ref->opnd) || opnd_is_abs_addr(ref->opnd))) {
    if ((void *) 0xffffffffff5ff0a8 == opnd_get_addr(ref->opnd))
    return false;
}

return true;

}

Now, client works and I do not get a segmentation fault. Here is the output.

" /home/etem/workspace/hello/Debug/hello <Starting application /home/etem/workspace/hello/Debug/hello (3706)> <Paste into GDB to debug DynamoRIO clients: set confirm off add-symbol-file '/home/etem/TOOLS/my-umbra-debug/build/bin/libsharedetect.so' 0x00000000720058a0 add-symbol-file '/lib/x86_64-linux-gnu/libc.so.6' 0x00007f3c14f43fa0 add-symbol-file '/lib64/ld-linux-x86-64.so.2' 0x00007f3c14cffaf0

<Initial options = -client_lib '/home/etem/TOOLS/my-umbra-debug/build/bin/libsharedetect.so;0;' -code_api -stack_size 56K -max_elide_jmp 0 -max_elide_call 0 -max_bb_instrs 0x200 -no_shared_bbs -no_shared_traces -thread_private -no_atomic_inlined_linking -no_shared_trace_ibl_routine -no_finite_bb_cache -no_finite_trace_cache -no_inline_ignored_syscalls -native_exec_default_list '' -no_native_exec_managed_code -no_indcall2direct > pid = 3706 Thread 1 says Hello! Thread 2 says Hi! <(1+x) Handling our fault in a TRY at 0x00000000712a3a5c> <Stopping application /home/etem/workspace/hello/Debug/hello (3706)>

Note that there is a message "(1+x) Handling our fault in a TRY at 0x00000000712a3a5c". I check the output of the client and it seems to correct.

derekbruening commented 10 years ago

From zhao...@google.com on September 27, 2013 13:26:53

Status: Fixed

DynamoRIO / dynamorio

client porting from DR 3 to DR 4 #1259

ifdef LINUX

else

endif /_ LINUX */

0 0x000000004f563bc2 in ?? ()

1 0x00007fff0721a100 in ?? ()

2 0x00007fa115a09235 in ?? () from /lib64/ld-linux-x86-64.so.2

3 0x00000000004007df in main () at ../hello.c:43

0 0x000000004f563bc2 in ?? ()

1 0x00007fff0721a100 in ?? ()

2 0x00007fa115a09235 in ?? () from /lib64/ld-linux-x86-64.so.2

3 0x00000000004007df in main () at ../hello.c:43

0 0x0000000050556bf9 in ?? ()

1 0x00007fa1147255a0 in ?? ()

2 0x00007fa1152ff3f8 in get_nprocs () from /lib/x86_64-linux-gnu/libc.so.6