gh-137293: Ignore Exceptions when searching ELF File in Remote Debug

[uxioandrade]

When calling search_elf_file_for_section from search_linux_map_for_section passing a file that either doesn't exist or can't be opened correctly for a variety of reasons, this will throw an exception regardless of whether that file contains PyRuntime. The call to search_linux_map_for_section can behave as expected if it does eventually open the file with PyRuntime. After discussion, this fix removes exceptions from search_linux_map_for_section

Tested manually with the following script:

import sys
import os
import time

os.chmod("/cpython/python.exe", 0x0000)
sys.remote_exec(77223, "./remote_code.py")

Before:

/cpython# ./python.exe trigger_script.py
OSError: Cannot open ELF file '/cpython/Modules/readline.cpython-315-aarch64-linux-gnu.so (deleted)' for section 'PyRuntime' search: No such file or directory

During handling of the above exception, another exception occurred:

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

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

Traceback (most recent call last):
  File "/cpython/trigger_script.py", line 11, in <module>
    sys.remote_exec(77223, "./remote_code.py")
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: PyRuntime address lookup failed during debug offsets initialization

Now

/cpython# ./python.exe trigger_script.py
RuntimeError: Failed to find the PyRuntime section in process 77223 on Linux platform

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

Traceback (most recent call last):
  File "/cpython/trigger_script.py", line 11, in <module>
    sys.remote_exec(77223, "./remote_code.py")
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: PyRuntime address lookup failed during debug offsets initialization

• Issue: SystemError: <built-in function remote_exec> returned a result with an exception set #137293

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[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.

[ZeroIntensity]

Please add a news entry, and if possible, a test case. We can probably test this by running remote_exec on a file with some weird permissions?

[ZeroIntensity]

From my understanding, this should always be true at this point. If search_elf_file_for_section returns 0, there's an exception set.

[uxioandrade]

It might be overly defensive but could there be no exceptions in case section is null here?

[ZeroIntensity]

I'd have argued that was its own issue, but per discussion it seems we should just remove exceptions from search_elf_file_for_section entirely. It's not called anywhere else.

[pablogsal]

I don't think we should print the exception. For example there are some normal conditions where we will find the target but we will have some exceptions while reading unrelated files and other cases and we don't want to confuse the users showing that error.

What do you think @godlygeek ?

[godlygeek]

I'm inclined to agree. Any problems encountered at this point aren't necessarily fatal, and there's no reason to ever report anything to the user if we go on to succeed.

[uxioandrade]

Please add a news entry, and if possible, a test case. We can probably test this by running remote_exec on a file with some weird permissions?

I might be off here but the problem with creating a test case for this is that when running remote_exec with a dummy file, the first ELF file at the top of the /proc//maps file will always be the one containing PyRuntime so the other file with weird permissions is never reached

[pablogsal]

Please add a news entry, and if possible, a test case. We can probably test this by running remote_exec on a file with some weird permissions?

I might be off here but the problem with creating a test case for this is that when running remote_exec with a dummy file, the first ELF file at the top of the /proc//maps file will always be the one containing PyRuntime so the other file with weird permissions is never reached

You can try with a build with --enable-shares but don't worry about a test case, it's going to be too complex. You can manually test it though by forcing a failure by hand and confirming it works

[ZeroIntensity]

Ok, sure, no test is fine.

I don't think search_elf_file_for_section should be setting exceptions at all, right? If we're only going to clear it, it'd be better to omit them entirely.

[uxioandrade]

Ok, sure, no test is fine.

I don't think search_elf_file_for_section should be setting exceptions at all, right? If we're only going to clear it, it'd be better to omit them entirely.

Yeah that makes a lot of sense, I just removed the exceptions from search_elf_file_for_section

[uxioandrade]

Please add a news entry, and if possible, a test case. We can probably test this by running remote_exec on a file with some weird permissions?

I might be off here but the problem with creating a test case for this is that when running remote_exec with a dummy file, the first ELF file at the top of the /proc//maps file will always be the one containing PyRuntime so the other file with weird permissions is never reached

You can try with a build with --enable-shares but don't worry about a test case, it's going to be too complex. You can manually test it though by forcing a failure by hand and confirming it works

Sweet, that sounds good, I just added my manual test details in the description

[serhiy-storchaka]

I do not think that silencing all exceptions indiscriminately is a good idea. This may remove useful information.

What if just add PyErr_Clear() before calling search_elf_file_for_section() (or at the beginning of it)?