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

Fix gdb.attach not working properly in x-terminal-emulator #2363

Closed
wants to merge 1 commit into from

Conversation

cnitlrt
Copy link

@cnitlrt cnitlrt commented Mar 3, 2024

fix: #2362

@peace-maker
Copy link
Member

Hey, was the issue solved externally?

@cnitlrt
Copy link
Author

cnitlrt commented Mar 14, 2024

nop...
Perhaps my proposed solution may not be the most efficient or elegant. Should I close the pull request and issue, or would it be advisable to consider reopening them?

@peace-maker
Copy link
Member

I'm afraid of race conditions when just adding one. Can we get the new pid more deterministically? We can at least check the proc.children() of the parent terminal somehow?

@cnitlrt
Copy link
Author

cnitlrt commented Mar 22, 2024

I'm afraid of race conditions when just adding one. Can we get the new pid more deterministically? We can at least check the proc.children() of the parent terminal somehow?

Hello, I've made some modifications to the code. Now, it can address my issue without impacting #1922

@peace-maker
Copy link
Member

Can you explain your reasoning behind this change please?

@cnitlrt
Copy link
Author

cnitlrt commented Mar 28, 2024

Can you explain your reasoning behind this change please?

Certainly, when debugging, I found that unlike tmux, gnome-terminal does not provide a method to directly retrieve the window pid (gdb_pid) such as through '-F' '#{pane_pid}', '-P'. When initialized using subprocess, gnome-terminal immediately pops up the window which has already been launched by the time wait_for_debugger is invoked. Consequently, at this juncture, the gdb_pid that we obtain through the p.pid method is actually the pid of the window, which is already operational. Henceforth, all we need to do is to ensure a successful trace to the process pid without disrupting the execution logic of tmux #1922 To achieve this, I switched 'break' to 'continue'. The system will subsequently keep invoking trace(pid) until it's not None, indicating that the process has been correctly traced.

@peace-maker
Copy link
Member

The idea of that loop was to stop waiting for the debugger to attach to the process when the debugger exits itself. So this patch isn't the way to go.

I've recently faced a similar problem with launching gdb under WSL2 and fixed it in #2470 by waiting for the youngest new gdb process with a newer pid than the terminal we just started. It appears to be a good-enough and that logic could be reused here too?

@cnitlrt
Copy link
Author

cnitlrt commented Oct 1, 2024

Hello sir, I installed the latest version of pwntools via pip in a new environment and retested. The issue is no longer present. However, I noticed that the pip-installed pwntools hasn't yet merged #2470 , so I'm unsure if it's related to my environment. Nonetheless, the issue is resolved. Thank you!

@peace-maker
Copy link
Member

You updated to 4.13.X? #2470 is only active when running in WSL2, so it shouldn't help in your case on Ubuntu. Do you still use gnome-terminal? It's weird that this fixed itself, but I'll take it. If you run into this problem again, please open a new issue 👍

@peace-maker peace-maker closed this Oct 1, 2024
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.

x-terminal-emulator gdb.attach not working properly
2 participants