Segfault in ~ThreadStateCreator on shutdown on Python 3.11 #411
Comments
|
For additional context, here is is the stack trace for the main thread from the same coredump |
shaldengeki
referenced
this issue
in shaldengeki/monorepo
Sep 24, 2024
Bumps [greenlet](https://github.com/python-greenlet/greenlet) from 3.0.3 to 3.1.1. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/python-greenlet/greenlet/blob/master/CHANGES.rst">greenlet's changelog</a>.</em></p> <blockquote> <h1>3.1.1 (2024-09-20)</h1> <ul> <li>Fix crashes on 32-bit PPC Linux. Note that there is no CI for this, and support is best effort; there may be other issues lurking. See <code>issue 422 <https://github.com/python-greenlet/greenlet/issues/422></code>_.</li> <li>Remove unnecessary logging sometimes during interpreter shutdown. See <code>issue 426 <https://github.com/python-greenlet/greenlet/issues/426></code>_.</li> <li>Fix some crashes on 32-bit PPC MacOS. This is a very old platform, and is only known to be tested on beta versions of an operating system that was never released, using the GCC 14 only provided by MacPorts; it may or may not work on the final MacOS X release that supported 32-bit PowerPC. It has the known issue of leaking memory when greenlets are used in multiple threads. Help debugging this would be appreciated. See <code>PR 419 <https://github.com/python-greenlet/greenlet/pull/419></code>_.</li> </ul> <h1>3.1.0 (2024-09-10)</h1> <p>.. note::</p> <pre><code>This will be the last release to support Python 3.7 and 3.8. </code></pre> <ul> <li>Adds support for Python 3.13.</li> </ul> <p>.. note::</p> <p>greenlet will not work in no-gil (free threaded) builds of CPython. Internally, greenlet heavily depends on the GIL.</p> <ul> <li>Greatly reduce the chances for crashes during interpreter shutdown. See <code>issue 411 <https://github.com/python-greenlet/greenlet/issues/411></code>_.</li> </ul> <h2>Platform Support</h2> <p>Support for the following platforms was contributed by the community. Note that they are untested by this project's continuous integration services.</p> <ul> <li>Hitachi's <code>SuperH CPU <https://github.com/python-greenlet/greenlet/issues/166></code>_.</li> <li><code>NetBSD on PowerPC. <https://github.com/python-greenlet/greenlet/pull/402></code>_</li> <li>RiscV 64 with <code>-fno-omit-frame-pointer <https://github.com/python-greenlet/greenlet/pull/404></code><em>. Note that there are <code>known test failures <https://github.com/python-greenlet/greenlet/issues/403></code></em>, so this</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/python-greenlet/greenlet/commit/dd0a948da112a574864b518e5739bd90d068a1b0"><code>dd0a948</code></a> Preparing release 3.1.1</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/ab8d3bc1245f0e454cd3865009f6332a8c0090a0"><code>ab8d3bc</code></a> Disable thread-local cleanup on 32-bit MacOS PPC with GCC. This will result i...</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/e9db22a94101e10909829c198b6d693ccf11f48f"><code>e9db22a</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/429">#429</a> from python-greenlet/issue419redux</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/6081a16bb1c560262b34cf112896a6982756d02c"><code>6081a16</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/419">#419</a> from barracuda156/powerpc</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/dbf311a021d80aecb38033a9f44fcf13be9e7a6f"><code>dbf311a</code></a> Greater safety and fewer assumptions doing cross-thread cleanup.</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/9e8a90b1a47e1254df65057af444671e22ca61e0"><code>9e8a90b</code></a> Set back greenlet_thread_state.hpp file</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/1bf374f4d8aaa8039012f70f93249726d23bdf59"><code>1bf374f</code></a> Duplicate greenlet_thread_state.hpp history.</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/64e0b4f6ceaa5cc2debafe551caea1276aa84aa9"><code>64e0b4f</code></a> Copy greenlet_thread_state.hpp into TThreadStateCreator.hpp</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/358a2e8f20816a68e65703b5488dd0337722a9a9"><code>358a2e8</code></a> Keep greenlet_thread_state.hpp</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/5144f7070cd7882f643f6b16a3dbc9138dbbf483"><code>5144f70</code></a> Sigh. Pip hides compiler output which is, you know, important, and the only w...</li> <li>Additional commits viewable in <a href="https://github.com/python-greenlet/greenlet/compare/3.0.3...3.1.1">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We recently upgraded a service from Python 3.8 to 3.11, and from greenlet 1.1.3.post0 to 3.3.0 and have been seeing a decent amount of segfaults during shutdown in the
ThreadStateCreatordestructor. It seems that this ends up getting called after the interpreter has already shut down which leads to a null pointer inPyEval_AddPendingCall.I'm working on trying to get a minimal repro and reading through the changes that might have made this happen, but wanted to flag here in case anyone had some ideas on what changes might be leading to this.
As far as fixing it goes, I'm pretty sure it would be safe to check if the interpreter still exists before this call is made, and if so just exit, since presumably there wouldn't be much to cleanup anyways if the interpreter is gone. Without knowing the ultimate cause though, it feels if this is due to some race condition then doing a pre-check would likely just reduce but not eliminate the issue
The text was updated successfully, but these errors were encountered: