Tests crash on macos Sonoma #109981
Comments
sobolevn
added
tests
|
With more info: However, this is dependent on some other test, for now I don't know which one. |
Try to run: Then look into bisect file result. |
|
I wrote this simple script (because
set -e
tests=$(cat << EOF stringarray=($tests) for i in "${stringarray[@]}"; do And tests still pass. So, I think that we need several tests, not just two. |
|
@shamsherfairfest this is unrelated, please open a new issue with the minimal reproduction. We would be happy to help you in that case :) |
ok sure |
Did you run |
|
I've reproduced it with only three test files: Now, I need to find exact tests that are related. |
Wow, that's very helpful, thanks!
You may give a new try to bisect_cmd: And then: It should help to reduce the quantity of code that you have to review, by skipping many tests, and help you to find the minimum set of tests which trigger the bug. |
|
By the way, it would be interesting to have a "files" mode in bisect_cmd to filter test files, rather than test cases. |
|
I found all three offending tests 🎉 |
|
Reproducer: from xml.sax.xmlreader import InputSource
from xml.sax.expatreader import create_parser
from xml.sax.handler import feature_external_ges
class TestEntityRecorder:
def __init__(self):
self.entities = []
def resolveEntity(self, publicId, systemId):
self.entities.append((publicId, systemId))
source = InputSource()
source.setPublicId(publicId)
source.setSystemId(systemId)
return source
parser = create_parser()
parser.setFeature(feature_external_ges, True)
resolver = TestEntityRecorder()
parser.setEntityResolver(resolver)
try:
parser.feed(
'<!DOCTYPE external SYSTEM "unsupported://non-existing">\n'
)
except Exception:
pass
import socket
hostname = socket.gethostname()
ip = socket.gethostbyname(hostname)
from test.support import os_helper
os_helper.fd_count() |
I'm now curious about the interaction between SAX parser, gethostname(), gethostbyname() and fd_count(). IMO it's an OS bug, you might need attempt to go further and have like no "import", and even write a C reproducer. Tell me if you need help for that, so you can report it to Apple. We have a few core devs who are in touch with Apple. |
|
Is there a macOS crash report with stack trace? Check |
|
Minimizing reproducer even more: from xml.sax.expatreader import create_parser
from xml.sax.handler import feature_external_ges
parser = create_parser()
parser.setFeature(feature_external_ges, True)
try:
parser.feed(
'<!DOCTYPE external SYSTEM "unsupported://non-existing">\n'
)
except Exception:
pass
import socket
hostname = socket.gethostname()
ip = socket.gethostbyname(hostname)
import os
for fd in range(os.sysconf("SC_OPEN_MAX")):
fd2 = os.dup(fd)
# or
# import fcntl
# for fd in range(os.sysconf("SC_OPEN_MAX")):
# fcntl.fcntl(fd, fcntl.F_DUPFD_CLOEXEC, 0)It crashes on this line: Line 2594 in b987fdb @ned-deily I don't see a stacktrace :( |
|
So, the crash goes away if I just change cpython/Lib/xml/sax/saxutils.py Line 365 in b987fdb f = b''. If I do that it switches to OSError: [Errno 24] Too many open files
Not sure what role |
|
You may not get a crash dump file if the executable is not running as an app bundle. Using the python.org 3.12.0 for macOS to run the minimal reproducer above, I get a crash file with the following relevant info: According to some Apple developer documentation:
So it would seem this is a test case error with consequnces on macOS. Perhaps the first part of the test (using |
|
If I run @sobolevn's script above I also get a crash, and get the following information on open files using lsof(1): The crash happens due to calling dup on file descriptor 3: BTW. The earlier script using Running the problematic test cases gives the same crash: From the limited research I've done it is possible to detect if a file descriptor is guarded using the undocumented That said, the easier fix on (recent?) versions of macOS is to use |
|
With the patch below diff --git a/Lib/test/support/os_helper.py b/Lib/test/support/os_helper.py
index 46ae53aa11..ca0b321f9e 100644
--- a/Lib/test/support/os_helper.py
+++ b/Lib/test/support/os_helper.py
@@ -600,6 +600,15 @@ def fd_count():
except FileNotFoundError:
pass
+ if sys.platform == "darwin":
+ try:
+ names = os.listdir("/dev/fd")
+ # Subtract one because listdir() internally opens a file
+ # descriptor to list the content of the /proc/self/fd/ directory.
+ return len(names) - 1
+ except FileNotFoundError:
+ pass
+
MAXFD = 256
if hasattr(os, 'sysconf'):
try: |
This fixes a crash on macOS 14 when running ``./python.exe -m test test_sax test_socket test_support``. The root cause of this is a macOS feature where file descriptors used by system libraries are guarded an will cause a hard crash when used in "user" code.
Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. Co-authored-by: Victor Stinner <vstinner@python.org>
Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. (cherry picked from commit 953ee62) Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com> Co-authored-by: Victor Stinner <vstinner@python.org>
Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. (cherry picked from commit 953ee62) Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com> Co-authored-by: Victor Stinner <vstinner@python.org>
…2824) gh-109981: Fix support.fd_count() on macOS 14 (GH-112797) Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. (cherry picked from commit 953ee62) Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com> Co-authored-by: Victor Stinner <vstinner@python.org>
…2825) gh-109981: Fix support.fd_count() on macOS 14 (GH-112797) Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. (cherry picked from commit 953ee62) Co-authored-by: Ronald Oussoren <ronaldoussoren@mac.com> Co-authored-by: Victor Stinner <vstinner@python.org>
Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. Co-authored-by: Victor Stinner <vstinner@python.org>
Use scanning "/dev/fd/" on macOS in support.fd_count(). That's both more efficient than scanning all possible file descriptors, and avoids crashing the interpreter when there are open "guarded" file descriptors. "Guarded" file descriptors are a macOS feature where file descriptors used by system libraries are marked and cause hard crashes when used by "user" code. Co-authored-by: Victor Stinner <vstinner@python.org>
Crash report
I've experienced a crash on
mainbranch.I just used
./python.exe -m testThis is the all output I have for now.
Cannot reproduce with smaller set of tests.
Linked PRs
The text was updated successfully, but these errors were encountered: