You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Memory access violation on fatal error with Windows #116502
I'm running a C++ application with an embedded python interpreter.
The callstack is:
_Py_FatalErrorFormat() -> which calls fatal_error() with msg = NULL
fatal_error()
fatal_output_debug()
strlen() -> memory access violation on null pointer
CPython versions tested on:
3.11
Operating systems tested on:
Windows
Output from running 'python -VV' on the command line:
It's the cpython code itself that is calling fatal_output_debug () with a NULL message.
I gave the callstack in the description but I can give a more detailed one as follow:
Python\pylifecycle.c (3412): fatal_error(fd, 0, NULL, NULL, -1); // calls fatal_error () with msg = NULL
Python\pylifecycle.c (3363): fatal_output_debug(msg);
Python\pylifecycle.c (3089): msglen = strlen(msg); // crashes because strlen () should be called with a valid pointer and not null
I've proposed a pull request since one year but the issue is not progressing. @ericvsmith asked if NULL is a valid value for fatal_output_debug (). I have no idea.
As it is not progressing, I will propose another pull request to don't call fatal_output_debug () with NULL...
One possibility is that someone is calling _Py_FatalError or Py_FatalError with a NULL argument, which shouldn't be allowed, hence the crash. I would either suggest checking if we don't do it in CPython or check if the C++ application isn't doing this.
If we don't do this in CPython (namely all calls to _Py_FatalError are safe), then the issue is likely with the C++ application.
I have modified my pull request to fix the cpython code to don't call fatal_output_debug with NULL argument.
When msg = NULL, fatal_error will call fatal_output_debug with <message not set>.
This is homogeneous with pylifecycle.c line 3089: PUTS(fd, "<message not set>");
Activity
emmatyping commentedon May 26, 2025
Hi @dlaugt, do you have more information about what is calling fatal_output_debug with a NULL message?
dlaugt commentedon Jun 20, 2025
Hi @emmatyping,
It's the cpython code itself that is calling fatal_output_debug () with a NULL message.
I gave the callstack in the description but I can give a more detailed one as follow:
Python\pylifecycle.c (3412): fatal_error(fd, 0, NULL, NULL, -1); // calls fatal_error () with msg = NULL
Python\pylifecycle.c (3363): fatal_output_debug(msg);
Python\pylifecycle.c (3089): msglen = strlen(msg); // crashes because strlen () should be called with a valid pointer and not null
I've proposed a pull request since one year but the issue is not progressing. @ericvsmith asked if NULL is a valid value for fatal_output_debug (). I have no idea.
As it is not progressing, I will propose another pull request to don't call fatal_output_debug () with NULL...
picnixz commentedon Jun 20, 2025
One possibility is that someone is calling
_Py_FatalErrororPy_FatalErrorwith a NULL argument, which shouldn't be allowed, hence the crash. I would either suggest checking if we don't do it in CPython or check if the C++ application isn't doing this.If we don't do this in CPython (namely all calls to
_Py_FatalErrorare safe), then the issue is likely with the C++ application.dlaugt commentedon Jun 20, 2025
I have modified my pull request to fix the cpython code to don't call
fatal_output_debugwith NULL argument.When msg = NULL,
fatal_errorwill callfatal_output_debugwith<message not set>.This is homogeneous with pylifecycle.c line 3089:
PUTS(fd, "<message not set>");_Py_FatalErrorFormat()is called on Windows #145498 as a duplicate of this issuee4lam commentedon Mar 7, 2026