Skip to content

Memory access violation on fatal error with Windows #116502

Open

Description

@dlaugt

Crash report

What happened?

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:

No response

Linked PRs

Activity

  1. added
    type-crashA hard crash of the interpreter, possibly with a core dump
    on Mar 8, 2024
  2. emmatyping commented on May 26, 2025

    @emmatyping
    Member

    Hi @dlaugt, do you have more information about what is calling fatal_output_debug with a NULL message?

  3. added
    pendingThe issue will be closed if no feedback is provided
    on May 26, 2025
  4. dlaugt commented on Jun 20, 2025

    @dlaugt
    Author

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

  5. added
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    and removed
    pendingThe issue will be closed if no feedback is provided
    on Jun 20, 2025
  6. picnixz commented on Jun 20, 2025

    @picnixz
    Member

    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.

  7. added
    pendingThe issue will be closed if no feedback is provided
    on Jun 20, 2025
  8. dlaugt commented on Jun 20, 2025

    @dlaugt
    Author

    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>");

  9. removed
    pendingThe issue will be closed if no feedback is provided
    on Jun 20, 2025
  10. e4lam commented on Mar 7, 2026

    @e4lam
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowsinterpreter-core(Objects, Python, Grammar, and Parser dirs)topic-C-APItype-crashA hard crash of the interpreter, possibly with a core dump

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions