-
-
Notifications
You must be signed in to change notification settings - Fork 31k
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
gh-120754: Add a strace helper and test set of syscalls for open().read(), Take 2 #123413
Conversation
…s for o… (python#123303) This reverts commit 52caaef.
NOTE: This needs a full buildbot test pass before merge, see: python#121143 (comment). 1. Added `statx` to set of allowed syscall forms (Should make Raspian bot pass). 2. Check that the `fd` returned from `open` is passed to all future calls. This helps ensure things like the `stat` call uses the file descriptor rather than the `filename` to avoid TOCTOU isuses. 3. Update the `Path().read_bytes()` test case to additionally validate the reduction in`isatty`/`ioctl` + `seek` calls from python#122111 4. Better diagnostic assertion messagess from @gpshead, so when the test fails have first information immediately available. Makes remote CI debugging much simpler.
🤖 New build scheduled with the buildbot fleet by @hauntsaninja for commit e196d3d 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
I looked into the buildbot failures and they don't seem related to the changes I make here (full details below). Raspbian bot which failed post-merge on last PR, does pass here. Investigating buildbot failures:
test.test_asyncio.test_server.TestServer2.test_abort_clients``` 0:01:43 load avg: 8.22 [353/479/1] test.test_asyncio.test_server failed (1 failure) test_start_server_1 (test.test_asyncio.test_server.ProactorStartServerTests.test_start_server_1) ... skipped 'Windows only' test_start_server_1 (test.test_asyncio.test_server.SelectorStartServerTests.test_start_server_1) ... ok test_start_unix_server_1 (test.test_asyncio.test_server.SelectorStartServerTests.test_start_unix_server_1) ... ok test_abort_clients (test.test_asyncio.test_server.TestServer2.test_abort_clients) ... FAIL test_close_clients (test.test_asyncio.test_server.TestServer2.test_close_clients) ... ok test_wait_closed_basic (test.test_asyncio.test_server.TestServer2.test_wait_closed_basic) ... ok test_wait_closed_race (test.test_asyncio.test_server.TestServer2.test_wait_closed_race) ... ok test_unix_server_addr_cleanup (test.test_asyncio.test_server.UnixServerCleanupTests.test_unix_server_addr_cleanup) ... ok test_unix_server_cleanup_gone (test.test_asyncio.test_server.UnixServerCleanupTests.test_unix_server_cleanup_gone) ... ok test_unix_server_cleanup_prevented (test.test_asyncio.test_server.UnixServerCleanupTests.test_unix_server_cleanup_prevented) ... ok test_unix_server_cleanup_replaced (test.test_asyncio.test_server.UnixServerCleanupTests.test_unix_server_cleanup_replaced) ... ok test_unix_server_sock_cleanup (test.test_asyncio.test_server.UnixServerCleanupTests.test_unix_server_sock_cleanup) ... ok======================================================================
|
Bots which failed around |
The |
Could this get the "no news" label? (Internal changes). I think this is ready for a more full review again + run bots (merged current main in recently) Recent changes:
|
🤖 New build scheduled with the buildbot fleet by @hauntsaninja for commit 9e8b23d 🤖 If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
Buildbots look fairly clean. Three failed (AMD64 Windows10 PR, ARM64 Windows Non-Debug PR, ARM64 Windows PR), all with issues in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for sticking with this change!
It looks like if unknown syscalls are introduced the current test is fine with that. If you wanted to make a follow-up PR tightening that up, I'd be in favour of it. (I acknowledge that that maybe contradicts the advice in #121143 (comment) , but I think the similar name logic helps address the maintainability concern)
This does prevent additional |
All the newly added tests fail on Gentoo Linux with sandbox enabled. From a quick check, the test wrongly assumes that the first syscall reported by If I add some prints to get the list of syscalls, I get e.g. the following:
i.e. there's a bunch of extra "preparatory" calls before the |
Besides, given how fragile this thing is by design, there should be an easy way to disable it (e.g. via |
It's broken on musl (without any special environment) too:
|
Happy to work on making the state better on Gentoo. There are tradeoffs in the fragility, and I'm happy to iterate to get everything working well. Unfortunately not having a check like this has resulted in syscalls being re-added unintentionally (ex. bpo-21679 removed a double stat and gh-120754 removed a double stat again). In the short term I think the There looks like three cases to investigate/work on from this:
For 3, did anything in For all three of those I think the standard python process is either open a new issue or reopen the gh-120754 one. Happy to open one so can track these changes and get a fix landed. |
On a glibc system, only Could you open the bug, please? I still have lots to do today. |
…n().read(), Take 2 (python#123413)
…n().read(), Take 2 (python#123413)
Reapply GH-121143 with additional changes after it was reverted in GH-123303. Investigation why the bot broke + suggestions for improvements in #121143 (comment)
Note: This needs a buildbot trigger + pass before merge, see: #121143 (comment).
Changes from GH-121143:
statx
to set of allowed syscall forms (Should make Raspian bot pass).fd
returned from theopen
call is passed to all future calls. This helps ensure that thestat
call uses the file descriptor rather than thefilename
to avoid TOCTOU isuses.Path().read_bytes()
test case to additionally validate the reduction inisatty
/ioctl
+seek
calls from GH-120754: Disable buffering in Path.read_bytes #122111.