Crash in urllib/request.py proxy_bypass_macosx_sysconf #105912
Comments
Tristan971
added
the
type-crash
Tristan971
changed the title
|
Not sure it'll be particularly useful, but just in case, here's the more generic software crash report generated by macOS in this case. |
|
This appears to be a duplicate of #104578 given the first few lines of the error message. That issue is still open because this issue needs to be documented somewhere. The |
ronaldoussoren
added
the
pending
Indeed it seems like it is, sorry; didn't show up when I was searching the issue tracker somehow.
So I do see in that issue you quote, which is recent (May 2023), and the similar issue I linked (Oct 2016), and the one that one duped (Jan 2012 #58037), and on the 2016 mailing list exchange I also linked, and a few others that are now rather old... Clearly this issue keeps occuring, and one of the only comments I can find officially suggesting a position at all from CPython on whether it's a defect was in #58037 (comment) in 2012, with the commenter suggesting that "it is not fixable in Python." And I read the related blog post from Barry Warsaw on the matter. Very cool, but also quite puzzling that for a rather well-understood problem, we're still getting unexplained segfaults... From what I see:
But if that's all correct, then it sounds a lot like rather than a note in the docs that no-one will notice, os.fork should straight up refuse to execute on macOS 10.13+ unless the user has set some kind of "YES_PLEASE_ALLOW_OS_FORK_EVEN_IF_IT_IS_LIKELY_TO_CRASH" envvar, and that no matter the macOS version. Otherwise a library maintainer running their tests/CI on another version has almost no chance of even being aware of the issue... It is overall quite puzzling to have such an old and well-understood footgun dealt with with a "Python devs should just know to always exec right after fork for their stuff if it's to ever run on macOS; and if they don't, then oh well, they should have read the docs and paid close attention while doing so" approach... That sort of expectation reminds me much more of relatively arcane pre-initialization expectations in lower-level languages than of something to expect from what is the de-facto managed runtime of the most popular scripting (and arguably generally programming) language. :/ |
|
Removing The proxy getting code just ends up in crash reports because that and tkinter are the only stdlib extension modules that use high-level APIs. We cannot fix these crashes because it is platform behaviour we have no control over. And yes, that's annoying for us too. |
Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem.
ronaldoussoren
removed
the
pending
* gh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. Co-authored-by: Carol Willing <[email protected]>
…H-112871) * pythongh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. (cherry picked from commit 22511f7) Co-authored-by: Ronald Oussoren <[email protected]> Co-authored-by: Carol Willing <[email protected]>
…112871) * pythongh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. Co-authored-by: Carol Willing <[email protected]>
) (#113133) gh-105912: document gotcha with using os.fork on macOS (GH-112871) * gh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. (cherry picked from commit 22511f7) Co-authored-by: Ronald Oussoren <[email protected]> Co-authored-by: Carol Willing <[email protected]>
) (#113135) * gh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. (cherry picked from commit 22511f7) Co-authored-by: Carol Willing <[email protected]>
|
This platform limitation is now documented, I'm therefore closing this issue. |
…112871) * pythongh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. Co-authored-by: Carol Willing <[email protected]>
…112871) * pythongh-105912: document gotcha with using os.fork on macOS Using ``fork(2)`` on macOS when also using higher-level system APIs in the parent proces can crash on macOS because those system APIs are not written to handle this usage pattern. There's nothing we can do about this other than documenting the problem. Co-authored-by: Carol Willing <[email protected]>
Crash report
Python process crashes with a SIGABRT signal at the OS level (showing the standard software crash prompt of macOS, most of the time), and a python fatal error other times (the latter being shown here).
Unfortunately I don't have a minimal reproducer on hand.
However it looks exceptionally like a return of #72529 in the offending cause, as well as the workaround (setting the environment variable
no_proxyto*fixes it too).Which might share the same root cause (here: https://bugs.python.org/issue31818) at first glance.
Error messages
Your environment
on macOS 13.4 on arm (M1)
Note that I had the same issue on 3.10.12 and on some version (that I can't recall) of 3.9 before; long meant to report the bug but hadn't yet bothered
Linked PRs
The text was updated successfully, but these errors were encountered: