mr-ma / sip-eval

1 stars 0 forks source link

memcached detects and kills debugger #23

Open mr-ma opened 6 years ago

mr-ma commented 6 years ago

It seems like there is a library call in the memcached that terminates the program if a debugger is attached. Ideally, we should find that call and remove it.

anahitH commented 6 years ago

@mr-ma How do you reproduce the problem?

mr-ma commented 6 years ago

@anahitH Simply run OH on memcached. Make sure there are some asserts (oh.stats). GDB patcher always fails:

Program received signal SIGABRT, Aborted.
0x00007ffff79c8269 in raise (sig=6) at ../sysdeps/unix/sysv/linux/pt-raise.c:35
A debugging session is active.
anahitH commented 6 years ago

@mr-ma Please check updated memcached testapp bitcode. The name is debug_memcached_testapp.bc. After verifying that it works we can remove the old bitcode.

mr-ma commented 6 years ago

@anahitH Looks good!

mr-ma commented 6 years ago

@anahitH It is happening again :

([New Thread 0x7ffff73e8700 (LWP 17916)]
ok 50 - binary_pipeline_hickup
[Thread 0x7ffff73e8700 (LWP 17916) exited]
Signal handled: Interrupt.
ok 51 - shutdown
ok 52 - stop_server
[Inferior 1 (process 17878) exited normally]
Patched: 0  in  /home/sip/eval/binaries/debug_memcached_testapp.bc/10/18/1/debug_memcached_testapp.bctmp  saved as: /home/sip/eval/binaries/debug_memcached_testapp.bc/10/18/1/debug_memcached_testapp.bctmp
ERR. Some asserts are not patched! Patched= 0  Asserts= 11

To reproduce, just run the generator, it still fails for some binaries

anahitH commented 6 years ago

@mr-ma This seems to be another problem. As you can see from the log gdb exists normally. I'm not able to reproduce the problem with running generator, as resulting bitcodes do not have any asserts (the problem you've described earlier), however runing oh-binary-patch from oh project does patching without problems.

mr-ma commented 6 years ago

@anahitH You'd need to pull the latest SC, this way probably you will see some asserts in the bitcode. The patcher works fine for some binaries and fails for others. Please investigate and reassign this issue back to me, if you couldn't find the root cause.

anahitH commented 6 years ago

@mr-ma Thanks, after updating SC I see asserts inserted to the protected binary and now can see generator failing for some bitcodes. However the failure for me is related to OH patcher not patching asserts. E.g. for one of the bitcodes, there are 19 asserts and OH patcher is not patching any of those. After retrying three times generator fails and exists. Those 19 asserts are inserted to a functions that do not have any call sites. I wrote about this problem in issue #51 in input dependency analysis project.

If the failure you see is the one related to gdb, could you please send the bitcode gdb crashes on?

mr-ma commented 6 years ago

Those 19 asserts are inserted to a functions that do not have any call sites.

@anahitH Right, input dependency seems to be the root cause.