Skip to content

Excessive stack use in _PyModule_IsPossiblyShadowing #158918

Description

@Yhg1s

Bug report

While debugging a test failure of ft_utils.tests.test_localwrapper.TestLocalWrapperAttributes.test_recursion_guard I noticed _PyModule_IsPossiblyShadowing stack-allocating not one, but two MAXPATHLEN-sized wchar_t buffers. (The second buffer is only used when sys.path[0] is "", which should be pretty rare given that it's normalized very early on in Python's startup.) The two buffers push the function's stack size past 32k, which means a call to it while producing a RecursionError can cause a stack overrun.

I haven't been able to reproduce such a case because of other protections involved, but when _PyModule_IsPossiblyShadowing is inlined into _Py_module_getattro (via _Py_module_getattro_impl), any attribute lookup ends up using 32k+ stack and that is a much bigger deal. Arguably this is a case of bad inlining decisions, but since it's fairly trivial and equally arguably more efficient to heap allocate the buffers here (given that the second allocation is very unlikely to be necessary), I think we should fix _PyModule_IsPossiblyShadowing. I have a PR for this.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

Activity

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

Metadata

Metadata

Assignees

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions