All commit authors signed the Contributor License Agreement.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

@dlaugt Until now it wasn't bothering me, but could you avoid force-pushing? it rewrites the history and makes incremental reviews harder. TiA! (until now, you only changed 1 file so it was fine for me, but now that we need tests and a NEWS entry, it'll be better for us). We squash-merge at the end anyway, so don't worry.

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.

Good point. However, on Windows, when we call Py_FatalError, it writes the msg to stderr and to the debugger output (OutputDebugStringW). Perhaps, it would be consistent to do the same for _Py_FatalErrorFormat.

I have modified the pull request according to that. However, with this solution in term of performance, _Py_FatalErrorFormat has an extra vsnprintf and an extra malloc. If this is annoying, we can write a specific version of _Py_FatalErrorFormat for Windows with the extra vsnprintf and malloc and another version of _Py_FatalErrorFormat for non Windows without the extra vsnprintf and malloc.

But, at the end, if _Py_FatalErrorFormat should not write at all to the debugger output (OutputDebugStringW), I can go back to the previous pull request and add a check if (header) before OutputDebugStringW.

This is only a proposal. Up to the reviewers to decide.

@picnixz, ok I didn't know that the merges are squashed at the end... I will avoid to amend the commits next time.

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.

It should not be annoying to have this extra vsnprintf and malloc because _Py_FatalErrorFormat is not a simple error logging that could be called a huge number of times during the life time of the program. _Py_FatalErrorFormat itself terminates the program by calling abord or exit.

Good point. However, on Windows, when we call Py_FatalError, it writes the msg to stderr and to the debugger output (OutputDebugStringW). Perhaps, it would be consistent to do the same for _Py_FatalErrorFormat.

Oh, hmm, I think you're right. Py_FatalError does print it twice, so your original fix was correct. But we still need tests!

However, on Windows, when we call Py_FatalError, it writes the msg to stderr and to the debugger output (OutputDebugStringW). Perhaps, it would be consistent to do the same for _Py_FatalErrorFormat.

We can't use malloc. Py_FatalError is a function that's called in signal handlers, and malloc is not signal safe. For example, if we're in a SIGSEGV handler, the crash might have happened under a call to malloc, which acquires a lock. The malloc call in the handler will then deadlock.

We can't use malloc. Py_FatalError is a function that's called in signal handlers, and malloc is not signal safe. For example, if we're in a SIGSEGV handler, the crash might have happened under a call to malloc, which acquires a lock. The malloc call in the handler will then deadlock.

Ok I will see later in the weekend what could be done to avoid the malloc. However, _Py_FatalErrorFormat is using vfprintf on the shared stream (stderr). If I understand well, GNU seems to say that it could be an issue for signal handler:
https://www.gnu.org/software/libc/manual/html_node/Nonreentrancy.html

Yeah, that might be a bug on its own. Let's figure that out later.