gh-100795: avoid unexpected freeaddrinfo after failed getaddrinfo

[sebres]

Proposed PR fixes segfault gh-100795 - avoid unexpected freeaddrinfo if res becomes not NULL during invocation of getaddrinfo if it fails.
Previously this could cause double freeing and other hardly reproducible aftereffects, especially in multithreaded environment.

One could surely do return -1 instead of res = NULL & goto fail (in second case), like in

cpython/Modules/socketmodule.c

Line 1095 in 5ef90ee

return -1;

but this way it is minimal invasive (more consistent, remains safe against some merges or future implementations expecting goto fail to free some other handles, etc).

[cjw296]

Please base this off main

[sebres]

I know therefore I wrote that a rebase is needed.
This happens if development takes places in branches independently without any interim merge point to mainline.
Please reopen, I'll cherry pick that commits main-based.

[sebres]

OK, the branch is main-based now.
You can reopen it or forget it (because I don't understand why your time should be more valuable than my).
As I saw this chaos I marked this PR as draft, there was no reason at all to close it.

[arhadthedev]

there was no reason at all to close it.

Apologises if the swift closure appeared to be rude. GitHub fails to update PR's Commits and Files Changed tabs if a push creates massive changes. So it's way easier to create a new PR for a fixed branch instead of trying to somehow reset notifications and the tabs.

[arhadthedev]

By the way, branch miscreation happens regularily in the CPython repo so closing and recreation anew became a standard (and default / someway unquestionable) practice.

[vsajip]

branch miscreation happens regularily in the CPython repo

Yes, because new contributors apparently have missed this bit in the documentation ("Lifecycle of a Pull Request"):

Here is a quick overview of how you can contribute to CPython:

• Create an issue that describes your change
• Create a new branch in Git from the main branch

(later steps omitted)

[sebres]

OK, new PR #101220 is there now.
FWIW, as already said, few simplest interim merge-marks of primary branches to each other up to main (simple merge-points of 3.9 -> 3.10 -> 3.11 -> main, without data/conflicts resolution, just to obtain new common ancestor, e. g. after some releases) could help again such kind of disaster, avoid large unmerged trees again and again and prevent such a chaos on GH side (regardless intentional or by possible user confusion)... let alone it'd help people actively developing against different branches or else often switching them (to find a bug source or target branch to backport, to bisect, blame etc pp).