closing application from client

[Paolo Piselli]

Is there a particular way to end a process gracefully from within a
dynamorio client? I.e., if a client has decided that an application
must be terminated, is it acceptable to just call std exit from within
the client, or will that cause important DR shutdown hooks to be bypassed?

[Qin Zhao]

One simple way is to redirect the application execution to call exit.

On Fri, Aug 12, 2011 at 7:49 PM, Paolo Piselli <ppis...@csail.mit.edu> wrote:

Is there a particular way to end a process gracefully from within a dynamorio client?  I.e., if a client has decided that an application must be terminated, is it acceptable to just call std exit from within the client, or will that cause important DR shutdown hooks to be bypassed?

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To post to this group, send email to dynamorio-users@googlegroups.com.
To unsubscribe from this group, send email to dynamorio-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dynamorio-users?hl=en.

--
http://people.csail.mit.edu/qin_zhao/

[Derek Bruening]

DR provides dr_abort().

[Qin Zhao]

Will DR still call those exit event if calling dr_abort 

Sent from my iPod

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.

To post to this group, send email to dynamor...@googlegroups.com.
To unsubscribe from this group, send email to dynamorio-use...@googlegroups.com.

[Derek Bruening]

dr_abort() will not call the exit events, and gives no control over the exit code, but it does remove any .1config* file, and if we add any IPC APIs it will clean up any state there.  Picking dr_abort() vs having the app exit depends on the situation: dr_abort() is normally used on an error.  I can't tell from the question what's desired here.

- Derek

[Paolo Piselli]

Ultimately I wish to terminate a badly behaved program, and set an error code in the exit status that will allow an external program to differentiate between a program that was intentionally terminated by my client as opposed to exited normally or was terminated for other reasons.

Unfortunatly dr_abort does not have this functionality.  The process termination appears to use a hardcoded exit status in win32/os.c#os_terminate.  I have switched to calling the kernel32 functions ExitProcess or TerminateProcess, however the exit status is not what I expect it to be.  I am guessing that this is because my external script is checking the exit status of the drrun command rather than the child process which actually the thing my client is terminating.

-Paolo

[Derek Bruening]

On Mon, Aug 15, 2011 at 07:27:37PM -0400, Paolo Piselli wrote:
> Unfortunatly dr_abort does not have this functionality. The process
> termination appears to use a hardcoded exit status in
> win32/os.c#os_terminate.

Yes, like I said, dr_abort gives no control over the exit code.

> I have switched to calling the kernel32
> functions ExitProcess or TerminateProcess

If you mean your client directly (natively) invokes those then you're going
to leave behind .1config* files when using drrun (as mentioned, dr_abort
cleans that up). Better to arrange for the app to invoke an exit routine.
Alternatively, propose a new DR API feature.

> however the exit status
> is not what I expect it to be. I am guessing that this is because
> my external script is checking the exit status of the drrun command
> rather than the child process which actually the thing my client is
> terminating.

drrun's exit status is explicitly set to be the same as the child
process (unless there's an error injecting).

- Derek

[Derek Bruening]

Note that this did get filed as issue 743 and is now in r1343 as
dr_exit_process().

- Derek