gh-116502: Fix memory access violation on fatal error with Windows

[dlaugt]

Check if msg pointer is not null before calling strlen().

• Issue: Memory access violation on fatal error with Windows #116502

[ghost]

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.

[ericvsmith]

Is NULL supposed to be valid value for fatal_output_debug()? If not, shouldn't the fix be to whatever is passing in NULL?

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

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

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

[picnixz]

It's a nice catch because at L3307, we have this kind of if (msg) check.

I would advise adding an assert(msg != NULL) in fatal_output_debug though and add a comment for fatal_error saying that msg = NULL is allowed.

[dlaugt]

I've added the assert(msg != NULL) in fatal_output_debug.

[ZeroIntensity]

Sorry to block, but I think this is the wrong fix. When fatal_error is called with a NULL message (via _Py_FatalErrorFormat), fatal_output_debug should not write the Fatal Python Error header, because the caller already wrote it. I think it makes more sense to not call fatal_output_debug at all if msg is NULL.

Two other things:

1. This is definitely testable, we should test _Py_FatalErrorFormat in _testinternalcapi.
2. I would have thought this needed a news entry, because this is a crash fix.

Bénédikt, what was your rationale behind skip news and no tests? I'm happy to defer if you have concerns about either.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[picnixz]

Ah I forgot about the NEWS. Since the OP committed quite a lot, there was the bot notif and I added the label just to reduce the noise, but I forgot to add one.

As for the tests, sure we can add some! I may have missed the fact that the header was already written. However the function has already some if (msg) checks so we should also change them if needed.

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

I may have missed the fact that the header was already written. However the function has already some if (msg) checks so we should also change them if needed.

No worries, it's not particularly intuitive. fatal_error can do a bunch of different weird things. In this case, msg will only be NULL when header is 0, but fatal_output_debug unconditionally writes the header.