Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Terminating client from a client thread

15 views
Skip to first unread message

Mohammad Ewais

unread,
Jan 12, 2025, 12:09:31 AMJan 12
to DynamoRIO Users
Hi, I am running a 64 thread application on a client that also spawns a new client thread at the beginning using `dr_create_client_thread`. The client thread is responsible for some housekeeping tasks, when it reaches a certain condition, it should exit and also cause the other 64 app threads to exit. Here lies my problem. For the client thread to exit, I simply need to exit/return from it. But causing the application threads to exit has proved elusive for me. Here's what I tried:
1. Directly calling `dr_exit_process` from the client thread before it exits. This seems to only affect the client thread but not the app threads. So, I assume it would only work if called from within the app threads. If I remember correctly, I also didn't have any luck with `dr_abort`. That said, I want my exit event to be triggered, so `dr_abort` isn't an option anyway.
2. Based on #1, I tried calling `dr_nudge_client_ex` from the client thread, giving it the `process_id_t` of the main application thread. In the nudge event I then call `dr_exit_process`. However, it seems the nudge also has no effect, as the nudge event never actually gets executed.

So, how do I achieve this? What am I doing wrong?

Derek Bruening

unread,
Jan 13, 2025, 12:39:57 PMJan 13
to Mohammad Ewais, DynamoRIO Users
On Sun, Jan 12, 2025 at 12:09 AM Mohammad Ewais <mohammad...@gmail.com> wrote:
Hi, I am running a 64 thread application on a client that also spawns a new client thread at the beginning using `dr_create_client_thread`. The client thread is responsible for some housekeeping tasks, when it reaches a certain condition, it should exit and also cause the other 64 app threads to exit. Here lies my problem. For the client thread to exit, I simply need to exit/return from it. But causing the application threads to exit has proved elusive for me. Here's what I tried:
1. Directly calling `dr_exit_process` from the client thread before it exits. This seems to only affect the client thread but not the app threads. So, I assume it would only work if called from within the app threads. If I remember correctly, I also didn't have any luck with `dr_abort`. That said, I want my exit event to be triggered, so `dr_abort` isn't an option anyway.

You are presumably on Linux, where a client thread is in a separate thread group from the app, which is a very deliberate choice in order to provide private itimers and avoid parent-process-wide signals.  As a side effect, SYS_exit_group only exits the client's group and not the app's.
 
2. Based on #1, I tried calling `dr_nudge_client_ex` from the client thread, giving it the `process_id_t` of the main application thread. In the nudge event I then call `dr_exit_process`. However, it seems the nudge also has no effect, as the nudge event never actually gets executed.

I would think this would work.  Can you double check you passed the parent thread group id?  Walk through the nudge code in the debugger and make sure it goes into the non-internal path at the bottom of nudge_internal() in core/nudge.c and actually sends a signal to the app's group.  Does that signal arrive in the debugger?
 

So, how do I achieve this? What am I doing wrong?

--
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 visit https://groups.google.com/d/msgid/dynamorio-users/2ea182b8-aea7-4d28-84fa-45ca5274ced5n%40googlegroups.com.

Mohammad Ewais

unread,
Jan 14, 2025, 12:07:32 AMJan 14
to DynamoRIO Users
So, I used gdb to trace what was going on. It was correctly going through the non-internal path, and the main app thread was correctly receiving a SIGILL. The issue was that it happened to be in a FUTEX_WAIT when it received the SIGILL, which somehow prevented it from getting affected by it?!
So, instead of the nudge, I now set a shared variable and check it after getting out of the FUTEX_WAIT, that works fine, but I am now running into another problem.

I now call `dr_exit_process` from the main app thread. It seems to have an effect of exit instead of exitgroup system call. The main app thread is the one that created all the other 63 threads, but on calling `dr_exit_process` it dies alone and leaves the other threads hanging. How do I make them all exit?

Derek Bruening

unread,
Jan 14, 2025, 12:30:54 PMJan 14
to Mohammad Ewais, DynamoRIO Users
On Tue, Jan 14, 2025 at 12:07 AM Mohammad Ewais <mohammad...@gmail.com> wrote:
So, I used gdb to trace what was going on. It was correctly going through the non-internal path, and the main app thread was correctly receiving a SIGILL. The issue was that it happened to be in a FUTEX_WAIT when it received the SIGILL, which somehow prevented it from getting affected by it?!

Something is wrong there: a nudge should be acted on.  Whose FUTEX_WAIT, the app's or DR's?  If the app's, the signal should interrupt it and the app should go back to dispatch and see the pending nudge flag.  If DR's it should also see the pending nudge when the restarted wait is over: what is it waiting for?
 
So, instead of the nudge, I now set a shared variable and check it after getting out of the FUTEX_WAIT, that works fine, but I am now running into another problem.

I now call `dr_exit_process` from the main app thread. It seems to have an effect of exit instead of exitgroup system call. The main app thread is the one that created all the other 63 threads, but on calling `dr_exit_process` it dies alone and leaves the other threads hanging. How do I make them all exit?

Figure out why SYS_exit_group didn't exit them: is this a weird app that has the other threads in separate thread groups?
 



On Monday, January 13, 2025 at 12:39:57 PM UTC-5 Derek Bruening wrote:
On Sun, Jan 12, 2025 at 12:09 AM Mohammad Ewais <mohammad...@gmail.com> wrote:
Hi, I am running a 64 thread application on a client that also spawns a new client thread at the beginning using `dr_create_client_thread`. The client thread is responsible for some housekeeping tasks, when it reaches a certain condition, it should exit and also cause the other 64 app threads to exit. Here lies my problem. For the client thread to exit, I simply need to exit/return from it. But causing the application threads to exit has proved elusive for me. Here's what I tried:
1. Directly calling `dr_exit_process` from the client thread before it exits. This seems to only affect the client thread but not the app threads. So, I assume it would only work if called from within the app threads. If I remember correctly, I also didn't have any luck with `dr_abort`. That said, I want my exit event to be triggered, so `dr_abort` isn't an option anyway.

You are presumably on Linux, where a client thread is in a separate thread group from the app, which is a very deliberate choice in order to provide private itimers and avoid parent-process-wide signals.  As a side effect, SYS_exit_group only exits the client's group and not the app's.
 
2. Based on #1, I tried calling `dr_nudge_client_ex` from the client thread, giving it the `process_id_t` of the main application thread. In the nudge event I then call `dr_exit_process`. However, it seems the nudge also has no effect, as the nudge event never actually gets executed.

I would think this would work.  Can you double check you passed the parent thread group id?  Walk through the nudge code in the debugger and make sure it goes into the non-internal path at the bottom of nudge_internal() in core/nudge.c and actually sends a signal to the app's group.  Does that signal arrive in the debugger?
 

So, how do I achieve this? What am I doing wrong?

--
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 visit https://groups.google.com/d/msgid/dynamorio-users/2ea182b8-aea7-4d28-84fa-45ca5274ced5n%40googlegroups.com.

--
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.
Reply all
Reply to author
Forward
0 new messages