Hey, was the issue solved externally?

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?

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?

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

Can you explain your reasoning behind this change please?

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.