Fatal Python error: _PyMem_DebugFree: Python memory allocator called without holding the GIL #325
Comments
|
Another variation of the same bug is this one. The following is printed to the console: Thread 6 got SIGSEGV: While thread 1 is the one that detected the error during finialization: I've confirmed that in both cases, it is deallocating the (1) In the parent, before we exit the function we have already called It is weirder, in that the |
|
Fixed (in that I cannot reproduce it anywhere anymore) in #326 |
github-actions bot
referenced
this issue
in MaRDI4NFDI/open-interfaces
Nov 7, 2022
Bumps [greenlet](https://github.com/python-greenlet/greenlet) from 1.1.3.post0 to 2.0.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>2.0.1 (2022-11-07)</h1> <ul> <li>Python 3.11: Fix a memory leak. See <code>issue 328 <https://github.com/python-greenlet/greenlet/issues/328></code>_ and <code>gevent issue 1924 <https://github.com/gevent/gevent/issues/1924></code>_.</li> </ul> <h1>2.0.0.post0 (2022-11-03)</h1> <ul> <li>Add <code>Programming Language :: Python :: 3.11</code> to the PyPI classifier metadata.</li> </ul> <h1>2.0.0 (2022-10-31)</h1> <ul> <li>Nothing changed yet.</li> </ul> <h1>2.0.0rc5 (2022-10-31)</h1> <ul> <li>Linux: Fix another group of rare crashes that could occur when shutting down an interpeter running multiple threads. See <code>issue 325 <https://github.com/python-greenlet/greenlet/issues/325></code>_.</li> </ul> <h1>2.0.0rc4 (2022-10-30)</h1> <ul> <li>Linux: Fix a rare crash that could occur when shutting down an interpreter running multiple threads, when some of those threads are in greenlets making calls to functions that release the GIL.</li> </ul> <h1>2.0.0rc3 (2022-10-29)</h1> <ul> <li>Python 2: Fix a crash that could occur when raising an old-style instance object.</li> </ul> <h1>2.0.0rc2 (2022-10-28)</h1> <ul> <li>Workaround <code>a CPython 3.8 bug <https://github.com/python/cpython/issues/81308></code>_ that could cause the interpreter to crash during an early phase of shutdown with the message "Fatal Python error: Python memory allocator called without</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/69f6483c41776fb9095c3fd7b02d3e4ede289c78"><code>69f6483</code></a> Preparing release 2.0.1</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/df2154d45b8cfa751de1fc9e6a95e0b09a53becf"><code>df2154d</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/python-greenlet/greenlet/issues/329">#329</a> from python-greenlet/issue328</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/aa6f2515b2fefced69be933952bd1f3319d0de58"><code>aa6f251</code></a> Python 3.11: Fix a memory leak switching to greenlets.</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/7389976dc748677dd4fce535b91ef07e4387c1d6"><code>7389976</code></a> Back to development: 2.0.1</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/0216c2ae008cb185292b136e34ba92ae3f40da6b"><code>0216c2a</code></a> Preparing release 2.0.0.post0</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/7e1704ccbf2ade357416b63d95d645120df1f4dc"><code>7e1704c</code></a> .github/workflows/tests.yml: Move to final release of 3.11</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/f18bff43df80c5190760dc2aedfa436a1fae7bed"><code>f18bff4</code></a> setup.py: Add Python 3.11 to the PyPI classifier metadata.</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/fc50ac173d0011492c19c87eb619017fdab47fd9"><code>fc50ac1</code></a> Back to development: 2.0.1</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/f9c29d90b1fd33e3ade1272f46e17dfe17d651e6"><code>f9c29d9</code></a> Preparing release 2.0.0</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/4ba1df63dcd40c8056f21117a91bf56d0be8a6eb"><code>4ba1df6</code></a> Back to development: 2.0.0rc6</li> <li>Additional commits viewable in <a href="https://github.com/python-greenlet/greenlet/compare/1.1.3.post0...2.0.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 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>
netbsd-srcmastr
referenced
this issue
in NetBSD/pkgsrc
Nov 22, 2022
2.0.1 (2022-11-07) ================== - Python 3.11: Fix a memory leak. See `issue 328 <https://github.com/python-greenlet/greenlet/issues/328>`_ and `gevent issue 1924 <https://github.com/gevent/gevent/issues/1924>`_. 2.0.0.post0 (2022-11-03) ======================== - Add ``Programming Language :: Python :: 3.11`` to the PyPI classifier metadata. 2.0.0 (2022-10-31) ================== - Nothing changed yet. 2.0.0rc5 (2022-10-31) ===================== - Linux: Fix another group of rare crashes that could occur when shutting down an interpeter running multiple threads. See `issue 325 <https://github.com/python-greenlet/greenlet/issues/325>`_. 2.0.0rc4 (2022-10-30) ===================== - Linux: Fix a rare crash that could occur when shutting down an interpreter running multiple threads, when some of those threads are in greenlets making calls to functions that release the GIL. 2.0.0rc3 (2022-10-29) ===================== - Python 2: Fix a crash that could occur when raising an old-style instance object. 2.0.0rc2 (2022-10-28) ===================== - Workaround `a CPython 3.8 bug <https://github.com/python/cpython/issues/81308>`_ that could cause the interpreter to crash during an early phase of shutdown with the message "Fatal Python error: Python memory allocator called without holding the GI." This only impacted CPython 3.8a3 through CPython 3.9a5; the fix is only applied to CPython 3.8 releases (please don't use an early alpha release of CPython 3.9). 2.0.0rc1 (2022-10-27) ===================== - Deal gracefully with greenlet switches that occur while deferred deallocation of objects is happening using CPython's "trash can" mechanism. Previously, if a large nested container held items that switched greenlets during delayed deallocation, and that second greenlet also invoked the trash can, CPython's internal state could become corrupt. This was visible as an assertion error in debug builds. Now, the relevant internal state is saved and restored during greenlet switches. See also `gevent issue 1909 <https://github.com/gevent/gevent/issues/1909>`_. - Rename the C API function ``PyGreenlet_GET_PARENT`` to ``PyGreenlet_GetParent`` for consistency. The old name remains available as a deprecated alias. 2.0.0a2 (2022-03-24) ==================== - Fix a crash on older versions of the Windows C runtime when an unhandled C++ exception was thrown inside a greenlet by another native extension. This is a bug in that extension, and the interpreter will still abort, but at least it does so deliberately. Thanks to Kirill Smelkov. See `PR 286 <https://github.com/python-greenlet/greenlet/pull/286>`_. - Musllinux wheels for aarch64 are now built, tested, and uploaded to PyPI. Thanks to Alexander Piskun. - This version of greenlet is known to compile and pass tests on CPython 3.11.0a6. Earlier 3.11 releases will not work; later releases may or may not work. See `PR 294 <https://github.com/python-greenlet/greenlet/pull/294>`_. Special thanks to Victor Stinner, Brandt Bucher and the CPython developers.
emilymclean
referenced
this issue
in TechlauncherFireApp/backend
Aug 13, 2023
Bumps [greenlet](https://github.com/python-greenlet/greenlet) from 1.0.0 to 2.0.2. <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>2.0.2 (2023-01-28)</h1> <ul> <li>Fix calling <code>greenlet.settrace()</code> with the same tracer object that was currently active. See <code>issue 332 <https://github.com/python-greenlet/greenlet/issues/332></code>_.</li> <li>Various compilation and standards conformance fixes. See <a href="https://redirect.github.com/python-greenlet/greenlet/issues/335">#335</a>, <a href="https://redirect.github.com/python-greenlet/greenlet/issues/336">#336</a>, <a href="https://redirect.github.com/python-greenlet/greenlet/issues/300">#300</a>, <a href="https://redirect.github.com/python-greenlet/greenlet/issues/302">#302</a>, <a href="https://redirect.github.com/python-greenlet/greenlet/issues/334">#334</a>.</li> </ul> <h1>2.0.1 (2022-11-07)</h1> <ul> <li>Python 3.11: Fix a memory leak. See <code>issue 328 <https://github.com/python-greenlet/greenlet/issues/328></code>_ and <code>gevent issue 1924 <https://github.com/gevent/gevent/issues/1924></code>_.</li> </ul> <h1>2.0.0.post0 (2022-11-03)</h1> <ul> <li>Add <code>Programming Language :: Python :: 3.11</code> to the PyPI classifier metadata.</li> </ul> <h1>2.0.0 (2022-10-31)</h1> <ul> <li>Nothing changed yet.</li> </ul> <h1>2.0.0rc5 (2022-10-31)</h1> <ul> <li>Linux: Fix another group of rare crashes that could occur when shutting down an interpeter running multiple threads. See <code>issue 325 <https://github.com/python-greenlet/greenlet/issues/325></code>_.</li> </ul> <h1>2.0.0rc4 (2022-10-30)</h1> <ul> <li>Linux: Fix a rare crash that could occur when shutting down an interpreter running multiple threads, when some of those threads are in greenlets making calls to functions that release the GIL.</li> </ul> <h1>2.0.0rc3 (2022-10-29)</h1> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/python-greenlet/greenlet/commit/45e78ee5dbefe91c201b8d2b492b2701248e4c4c"><code>45e78ee</code></a> Preparing release 2.0.2</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/b55ea9e05172e5cfd91ca00dda38895024104ce1"><code>b55ea9e</code></a> Improve type error messages. Refs <a href="https://redirect.github.com/python-greenlet/greenlet/issues/330">#330</a></li> <li><a href="https://github.com/python-greenlet/greenlet/commit/1784361e97545c520384cfe50796136c337d1763"><code>1784361</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/342">#342</a> from python-greenlet/issue334</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/f891cc2d340e2f7983719d6f625ade517785933f"><code>f891cc2</code></a> Attempt a fix for <a href="https://redirect.github.com/python-greenlet/greenlet/issues/334">#334</a></li> <li><a href="https://github.com/python-greenlet/greenlet/commit/ae570c56dbee9070b02eb2124f0b991cce52f4db"><code>ae570c5</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/341">#341</a> from python-greenlet/issue302</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/616df6049cca1d94f783447ad164e331b3044ead"><code>616df60</code></a> Stop using 'const PyObject*, per <a href="https://github.com/vstinner"><code>@vstinner</code></a></li> <li><a href="https://github.com/python-greenlet/greenlet/commit/880825b7f02c4e22d64eef2e16a015c6a629fdcd"><code>880825b</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/340">#340</a> from python-greenlet/new-actions</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/da25c7f3b07e55c2239f3e618cf29dea3c0864e0"><code>da25c7f</code></a> Moving to currently supported action versions.</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/424733f52b9d2ad1c0bf8abd58119bc27aec30c8"><code>424733f</code></a> Merge pull request <a href="https://redirect.github.com/python-greenlet/greenlet/issues/339">#339</a> from python-greenlet/issue300</li> <li><a href="https://github.com/python-greenlet/greenlet/commit/99cad0de1ee0af3c62d16415d1632d781fa3af60"><code>99cad0d</code></a> Fix setup.py encoding; bump github codeql from v2 to v2</li> <li>Additional commits viewable in <a href="https://github.com/python-greenlet/greenlet/compare/1.0.0...2.0.2">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>
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We fixed something similar earlier, but this has a distinct message and backtrace.
This is a rare, threading-based issue at shutdown, and only when development mode is enabled.
Occasionally, when CI is running
python -W ignore -u dns_mass_resolve.py(usually frompython -m gevent.tests.test__examplesviapython -m gevent.tests), the ubuntu builds (running with PYTHONDEVMODE=1) will crash:That test runs multiple greenlets in multiple threads, and exits the main thread at an arbitrary time, when many of the other threads are still busy.
In one core dump, I observe the main thread finalizing the interpreter. It's manipulating a dict, so it should be holding the GIL:
The thread that crashed is deallocating an object at the exit of a greenlet (
src/greenlet/greenlet.cpp:1296is the closing brace ofg_initialstubso we are destructing stack-based C++ objects — in this case, probably the reference to therun()function):All the other threads are blocked in the
poll()system call via a socket function, and so shouldn't be holding the GIL.The question is, how are we exiting a greenlet while not holding the GIL? By definition, we shouldn't have been able to switch to it without holding the GIL.
The text was updated successfully, but these errors were encountered: