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

Seemingly many ptracer issues #3930

Open
3 tasks
theIDinside opened this issue Mar 4, 2025 · 3 comments
Open
3 tasks

Seemingly many ptracer issues #3930

theIDinside opened this issue Mar 4, 2025 · 3 comments

Comments

@theIDinside
Copy link
Contributor

theIDinside commented Mar 4, 2025

From what I gather recording (and therefore emulating) ptracers is difficult. This will be a meta bug that also links to my repo that contains the various different programs that fail under an RR recording.

https://github.com/theIDinside/rr-waitpid-bug now contains a couple of different bugs:

All these have some multi-threaded nature to them.

@khuey
Copy link
Collaborator

khuey commented Mar 4, 2025

Is there a motivation for these? Just having a perfect reimplementation of ptrace is not really a goal. Supporting recording e.g. gdb or something on the other hand is a reasonable goal.

@theIDinside
Copy link
Contributor Author

As far as I know, gdb doesn't use signalfd nor have a dedicated thread to do waitpid operations on, though I don't see why they wouldn't want it. The reason why I am using it is because it makes multi process debugging just a lot easier, since a "main thread" can be concerned with actual debugger work, instead of being ground to a halt when heavier applications like browsers for instance spam wait statuses to the ptracer.

So is it of any real world use yet? No, so I can definitely accept it not being a priority for rr (but it would of course be important to me :P).

@theIDinside
Copy link
Contributor Author

theIDinside commented Mar 4, 2025

Is there a motivation for these? Just having a perfect reimplementation of ptrace is not really a goal. Supporting recording e.g. gdb or something on the other hand is a reasonable goal.

@khuey - I found an acceptable workaround in my case. I can use signalfd and just integrate the waitpid directly on the maintread because of it without offloading it to a separate thread, in my case it's a tiny bit less efficient, but it's more than acceptable.

In the debugger I'm writing I use signalfd + waitpid on a separate thread (but ptrace commands issued on the thread that actually created new processes, because this is required for TRACEME). I think we can close this entirely since a full compat with ptrace is probably not really what RR aims for any how.

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

No branches or pull requests

2 participants