receiving a detach signal in the middle of client's code

[wl mu]

Hi, @derekbruening and @AssadHashmi.

When I use DynamoRIO in debug mode to detach an instrumented process externally, I met the error like following:

Client bbcount is running
<received nudge mask=0x4 id=0x00000000 arg=0x0000000000000000>
<Detaching from application /home/wlmu/cpu2017/benchspec/CPU/602.gcc_s/run/run_base_refspeed_aarch64-perf-79749-64.0000/sgcc_base.aarch64-perf-79749-64 (513978)>
<Application /home/wlmu/cpu2017/benchspec/CPU/602.gcc_s/run/run_base_refspeed_aarch64-perf-79749-64.0000/sgcc_base.aarch64-perf-79749-64 (513978) DynamoRIO usage error : meta-instr faulted?  must set translation field and handle fault!>
<Usage error: meta-instr faulted?  must set translation field and handle fault! (/home/wlmu/dynamorio-master/dynamorio/core/translate.c, line 1060)
version 10.92.19885, custom build

This DOCHECK can be located in the following code snippet:

            if (instr_get_translation(inst) == NULL) {

                /* Clients are supposed to leave their meta instrs with

                 * NULL translations.  (DR may hit this assert for

                 * -optimize but we need to fix that by setting translation

                 * for all our optimizations.)  We assume we will never

                 * get an app fault here, so we fail if asked for full state

                 * since although we can get full app state we can't relocate

                 * in the middle of client meta code.

                 */

                ASSERT(instr_is_meta(inst));

                /* PR 302951: our clean calls do show up here and have full state.

                 * FIXME i#4219: This is not safe: see comment above.

                 */

                if (walk.in_clean_call)

                    translate_restore_clean_call(tdcontext, &walk);

                else

                    res = RECREATE_SUCCESS_PC; /* failed on full state, but pc good */

                /* should only happen for thread synch, not a fault */

                DOCHECK(1, {

                    if (!(instr_is_our_mangling(inst)  ||

                          tdcontext != get_thread_private_dcontext() ||

                          INTERNAL_OPTION(stress_recreate_pc) ||

                          tdcontext->client_data->is_translating)) {

                        CLIENT_ASSERT(false,

                                      "meta-instr faulted?  must set translation "

                                      "field and handle fault!");

                    }

                });

I think this error is caused by receiving the detachment signal in the middle of client's code. In this case, the instructions being translated is the meta instruction, which isn't a safe spot for the nudged thread.
Would you like to give me some advice for this problem？If possible, I hope to contribute some code to solve this problem.

Best regards,

Wenlong.

[wl mu]

Sometimes, I am also unable to attach to the running process of SPEC CPU 2017. Could you explain the reasons for this issue and suggest possible solutions?

[Enrico Deiana]

> Would you like to give me some advice for this problem？If possible, I hope to contribute some code to solve this problem.

Thank you for being willing to contribute!

Does this issue only happen with your own instrumentation? Did you leave the xl8s you provided as null?

> Sometimes, I am also unable to attach to the running process of SPEC CPU 2017. Could you explain the reasons for this issue and suggest possible solutions?

Do you get an error message about this?

[wl mu]

The error information of DynamoRIO attachment is like following:

injectee_munmap(0x71000000, 0x25e000) -> 0xffffffffffffffcf injectee_mmap(84, 0x71000000, 0x25e000, 0x7, 0x0, 0x12) -> (3): No such process injectee_prot(0x71000000, 0x25e000, 5) -> -3 injectee_prot(0x7125e000, 0x10000, 0) -> -3 injectee_munmap(0x7126e000, 0x15000) -> 0xfffffffffffffffd injectee_mmap(84, 0x7126e000, 0x15000, 0x3, 0x25e000, 0x12) -> (3): No such process injectee_prot(0x7126e000, 0x4b000, 3) -> -3 ERROR: unable to attach; check pid and system ptrace permissions

[wl mu]

dynamorio.org writes that 
"Alternatively, you can first run notepad.exe, and then use drrun to attach to it, but please note that attaching is an experimental feature and is not yet as well-supported as launching a new process:"
Could you tell me the possible reason for attachment failure?

[Derek Bruening]

There are many possible failure points as both attach and detach are complex.  Any particular failure instance generally requires detailed on-site debugging.  It is probably best to focus on one at a time.  For the first one in this thread, the detach in client instrumentation, Enrico was asking whether you have custom instrumentation there: or is that an unmodified bbcount sample client?  And unmodified DR?  The "synchall" for detach has to get every thread stopped at a point where a translation to app state is feasible; it retries with each thread until that point is found.  It sounds like one of those points failed to translate for what seemed to be a violation of translation invariants.  Please see https://dynamorio.org/API_BT.html#sec_translation "For meta instructions" for background on what that assert is about.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dynamorio-users/a24355c2-5ac5-4cb8-95ce-4f856bde4224n%40googlegroups.com.