Skip to content
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

DO NOT MERGE #3587

Merged
merged 2 commits into from
Sep 9, 2023
Merged

DO NOT MERGE #3587

merged 2 commits into from
Sep 9, 2023

Conversation

rocallahan
Copy link
Collaborator

No description provided.

@rocallahan rocallahan force-pushed the ignore-bad-stops branch 6 times, most recently from 4abb4a7 to 4392bfb Compare September 4, 2023 22:44
@rocallahan
Copy link
Collaborator Author

@khuey @Keno you might want to have a look at this. I think it's the right thing to do but it's somewhat painful. It's basically the culmination of a long series of patches I've landed over the last several weeks to try to improve task-exit handling.

@rocallahan rocallahan force-pushed the ignore-bad-stops branch 3 times, most recently from 8d51a1e to 8eeb8b7 Compare September 5, 2023 05:42
@rocallahan rocallahan force-pushed the ignore-bad-stops branch 6 times, most recently from 5970a88 to 1c9c6d8 Compare September 8, 2023 21:29
…age, because on new Ubuntus Firefox is a Snap package which we don't support in rr yet
…ematurely exited the stop, just ignore the stop.

This makes our state tracking more accurate. Before, when a task is booted out of a ptrace-stop via SIGKILL or equivalent while we're reading its state in `Task::did_waitpid`, we would treat the task as as if it were still stopped, even though now it is either running in the kernel towards PTRACE_EVENT_EXIT or reap, or else stopped in a new PTRACE_EVENT_EXIT stop which we will see in the next wait(). We would cover up the discrepancy by changing the stop to a fake PTRACE_EVENT_EXIT. Instead we now "tell the truth" that the task is not known to be stopped and instead we should wait for its next stop.

The downside is that this requires us to propagate the fact that the task is not actually stopped to various callers, including the callers of `Task::resume_execution`. This is annoying, but it's also helpful to consider how these callers should behave when a task is booted out of a ptrace-stop by SIGKILL and is no longer stopped. It's complex and hard to test, but the underlying kernel behavior is the problem.
@rocallahan
Copy link
Collaborator Author

I just ran 1000 concurrent instances of the cont_race test with no failures, so I'm feeling pretty good about this. I'll merge it.

@rocallahan rocallahan merged commit 024064f into master Sep 9, 2023
2 checks passed
@rocallahan rocallahan deleted the ignore-bad-stops branch October 31, 2023 05:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant