gh-139940: Handle RuntimeError when attaching to a non-existing process in pdb.py

[frostming]

Before change:

OSError: Cannot open process memory map file '/proc/5555/maps' for PID 5555 section search: No such file or directory

During handling of the above exception, another exception occurred:

RuntimeError: Failed to find the PyRuntime section in process 5555 on Linux platform

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/frost/workspace/cpython/Lib/runpy.py", line 198, in _run_module_as_main
    return _run_code(code, main_globals, None,
                     "__main__", mod_spec)
  File "/home/frost/workspace/cpython/Lib/runpy.py", line 88, in _run_code
    exec(code, run_globals)
    ~~~~^^^^^^^^^^^^^^^^^^^
  File "/home/frost/workspace/cpython/Lib/pdb.py", line 3650, in <module>
    pdb.main()
    ~~~~~~~~^^
  File "/home/frost/workspace/cpython/Lib/pdb.py", line 3579, in main
    attach(opts.pid, opts.commands)
    ~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/frost/workspace/cpython/Lib/pdb.py", line 3448, in attach
    sys.remote_exec(pid, connect_script.name)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: PyRuntime address lookup failed during debug offsets initialization

After change:

Error attaching to process: Cannot open process memory map file '/proc/5555/maps' for PID 5555 section search: No such file or directory

Close gh-139940

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[gaogaotiantian]

I think attaching to a non-exist process is a common case where we should produce better error messages. I have a feeling that the message should be even more explicit about "you have the wrong process id". @pablogsal and @godlygeek what do you think?

[godlygeek]

Sounds reasonable to me. Maybe we want to catch the RuntimeError on POSIX and handle it by attempting os.kill(pid, 0) and seeing if that fails as well. If it does, we could raise an exception saying "Either there is no process with pid {pid} or you do not have privileges to send signals to it". That wouldn't be reasonable to do in the sys.remote_exec implementation itself, since there's no requirement there that you be able to send signals to the process, but PDB assumes you'll be able to for Ctrl-C to work, so it'd be a reasonable thing to check at this layer.