-
Notifications
You must be signed in to change notification settings - Fork 557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HANG while running gcc with sample cbr: synchall fails to handle vfork properly #6853
Comments
This looks like a failure to suspend all the threads (a "synchall") when running The question is, what is The debug logs should give substantial help here. |
Firstly, the problem is indeed about Then, I dump the debug logs and find that gcc uses The last few lines of parent's thread log:
After that, no more output log. By removing
The new thread's log:
|
Who is the target thread of the suspend? Is it the vfork child which is no longer there? CLONE_VFORK suspends the parent until the child execs at which point the child should not be on the list of threads in the parent process. Is it incorrectly still on the list and that's why the parent thinks it has to suspend it? Though you'd think the debug build synchall at exit time would have hit such a relatively simple bug in our existing vfork tests (IIRC there are some). |
The child thread calls I suspect the issue is that we don't set the parent's suspend state when processing I switched from using gcc to a simple program that only includes |
My test program
Command:
|
We have For how to handle: to DR the vfork child is a different-thread-group different-sighand-table thread. DR's signal and itimer and other handlers should already handle the different sighand table and different thread group. It is just this suspension that is missing. If the kernel doesn't resume until execve or exit in the child, I guess DR needs new state in |
Describe the bug
When running
gcc hello.c -o hello
with the clientcbr
, dynamorio hangs. This was observed for both x86 and RISCV64.However, when we do not use
dr_flush_region()
anddr_redirect_execution()
in cbr.c, everything is OK! As we have inserted thejmp
instruction after clean call, cbr still works correctly withoutdr_flush_region()
anddr_redirect_execution()
(with performance loss perhaps).So, dr_redirect_execution() may involves some bugs. As we invoke
prepare_for_call_ex()
and other 'save' operations before clean call, I'm not sure it's right not to callcleanup_after_call_ex()
to restore when using the dr_redirect_execution() routine.X86 output log is:
Expected behavior
DO NOT use dr_redirect_execution() in cbr, we can run the program successfully:
Other information
hello_world.c
,ls
and so on) can run correctly.The text was updated successfully, but these errors were encountered: