[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: Just in case, I also ran asyncio_gc.py 10x times on the master branch. I just replaced asyncio.async with asyncio.ensure_future. In short, I consider that the bug is now fixed. I interrupted the test two times with CTRL+c. 9 runs were stopped correctly. 1

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: I ran threading_shutdown_interrupted.py 10 times on the master branch (at commit 9b8e74ca77da7167033917d155e5f55c67b92f14): it does no longer crash. I consider that the root issue is now fixed, so I close again the bug. Thanks Pablo for the helpful

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: New changeset d1c09896c3b91d0ad7e3a14fabecde268f70dac7 by Victor Stinner in branch '3.7': bpo-20526: Fix PyThreadState_Clear(): don't decref frame (GH-19120) (GH-19136) (GH-19137)

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

Change by STINNER Victor : -- pull_requests: +18499 pull_request: https://github.com/python/cpython/pull/19137 ___ Python tracker ___

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: New changeset e97c8b0688bc62959ced477d842fcd37992ef649 by Victor Stinner in branch '3.8': bpo-20526: Fix PyThreadState_Clear(): don't decref frame (GH-19120) (GH-19136) https://github.com/python/cpython/commit/e97c8b0688bc62959ced477d842fcd37992ef649

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

Change by STINNER Victor : -- pull_requests: +18498 pull_request: https://github.com/python/cpython/pull/19136 ___ Python tracker ___

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: New changeset 5804f878e779712e803be927ca8a6df389d82cdf by Victor Stinner in branch 'master': bpo-20526: Fix PyThreadState_Clear(): don't decref frame (GH-19120) https://github.com/python/cpython/commit/5804f878e779712e803be927ca8a6df389d82cdf --

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: > (This issue previously had "release blocker" priority before it was closed. > Now that it is re-opened does it still need that? I'm assuming not.) Techicanilly, it's a 3.9 regression but I don't think that it should be hold 3.9 release. So no, it's not a

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

Ned Deily added the comment: (This issue previously had "release blocker" priority before it was closed. Now that it is re-opened does it still need that? I'm assuming not.) -- nosy: +ned.deily priority: release blocker -> high versions: +Python 3.9 -Python 3.4

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

Change by STINNER Victor : -- pull_requests: +18481 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19120 ___ Python tracker ___

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)->gc.gc_refs >> (1)) != 0' failed.

STINNER Victor added the comment: Right now, threading_shutdown_interrupted.py does crash on the master branch (commit 05e4a296ecc127641160a04f39cc02c0f66a8c27). I reintroduced the bug with: commit 9ad58acbe8b90b4d0f2d2e139e38bb5aa32b7fb6 Author: Victor Stinner Date: Mon Mar 9 23:37:49

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: I encounter a quite similar issue with python 3.4.0 and cx_Oracle. Your issue is different, compare the top frames: My trace: #0 0x003f3a835c59 in raise () from /lib64/libc.so.6 #1 0x003f3a837368 in abort () from /lib64/libc.so.6 #2

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Antoine Pitrou added the comment: In cx_Oracle trace, visit_decref() is called on a NULL pointer which comes from an Exception. Unless C conventions changed, 0xb is not a NULL pointer :-) -- ___ Python tracker rep...@bugs.python.org

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: Unless C conventions changed, 0xb is not a NULL pointer :-) Ooops, I missed the B :-) By the way, my gdb example is wrong: you should pass self :-) #1 0x0048193a in BaseException_traverse (self=0x70f645f8, visit=0x43ab64 visit_decref,

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Sebastien Renard added the comment: Hello, I encounter a quite similar issue with python 3.4.0 and cx_Oracle. It segfault from time to time (hard to reproduce) on visit_decref at Modules/gcmodule.c:373. There were no issue with python 2.7. I did not test with 3.3. With gdb i got the following

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Antoine Pitrou added the comment: Hi Sebastien, Those symptoms are actually quite generic. If you want do diagnose your issue, I would suggest you compile a debug build of Python (./configure --with-pydebug), it will enable many additional checks (and of course be quite a bit slower too...).

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Sebastien Renard added the comment: Hi Antoine, Thanks for your quick answer. I compiled with debug and compile cx_oracle again. Here the stack trace with gdb. Hope it will help. Program received signal SIGSEGV, Segmentation fault. 0x0043ab98 in visit_decref (op=0xb, data=0x0)

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Sebastien Renard added the comment: Same issue with a fresh python 3.3.5: 361 if (PyObject_IS_GC(op)) { (gdb) backtrace #0 visit_decref (op=0xb, data=data@entry=0x0) at Modules/gcmodule.c:361 #1 0x0052d9da in BaseException_traverse (self=0x7156d328,

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Antoine Pitrou added the comment: Well, 0xb is an unlikely pointer value, especially since other dynamically-allocated pointers seem to lie in other memory areas. So it would look like there's some memory corruption here. As for whether it's a Python issue, try reproducing without

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Roundup Robot added the comment: New changeset 9ce58a73b6b5 by Victor Stinner in branch '3.4': Issue #20526, #19466: Revert changes of issue #19466 which introduces a http://hg.python.org/cpython/rev/9ce58a73b6b5 -- ___ Python tracker

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Charles-François Natali added the comment: Please revert. To debug, since I guess it's due to a memory corruption because objects are deallocated while they're still in use, you could try to use valgrind. Unfortunately, since it's due to a race condition, the overhead will probably make it

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Roundup Robot added the comment: New changeset 1166b3321012 by Victor Stinner in branch 'default': Issue #20526, #19466: Revert changes of issue #19466 which introduces a http://hg.python.org/cpython/rev/1166b3321012 -- nosy: +python-dev ___ Python

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: To debug, since I guess it's due to a memory corruption because objects are deallocated while they're still in use, you could try to use valgrind. Unfortunately, since it's due to a race condition, the overhead will probably make it really hard to reproduce

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: revert_19466.patch: Patch to revert changes of issue #19466. It restores how Python cleared threads in Python 3.3. -- keywords: +patch Added file: http://bugs.python.org/file34056/revert_19466.patch ___ Python

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20526 ___

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Changes by Guido van Rossum gu...@python.org: -- nosy: -gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20526 ___ ___ Python-bugs-list

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Antoine Pitrou added the comment: If wait_for_thread_shutdown() is interrupted, maybe Python should kill all other threads with pthread_kill() or something like that. Or wait_for_thread_shutdown() should maybe block SIGINT and SIGTERM signals using pthread_sigmark()? This sounds a bit

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Charles-François Natali added the comment: Random thoughts: - executor-created threads are daemon (unfortunately) - see issue #19466: I think that the change to clear the frame of daemon threads was a mistake -- ___ Python tracker

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: Random thoughts: - executor-created threads are daemon (unfortunately) Are you sure? I didn't see the daemon flag in ThreadPoolExecutor. -- ___ Python tracker rep...@bugs.python.org

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: Are you sure? I didn't see the daemon flag in ThreadPoolExecutor. Oh you're right, ThreadPoolExecutor does create daemon threads: class ThreadPoolExecutor(_base.Executor): ... def _adjust_thread_count(self): # When the executor gets lost, the

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: threading_shutdown_interrupted.py: simpler and reliable script to reproduce the bug. -- Added file: http://bugs.python.org/file34053/threading_shutdown_interrupted.py ___ Python tracker rep...@bugs.python.org

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: Charles-François wrote: see issue #19466: I think that the change to clear the frame of daemon threads was a mistake Good catch. If I reverted changes of #19466, threading_shutdown_interrupted.py doesn't crash anymore. It doesn't explain how the GC header

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

STINNER Victor added the comment: I set the priority to release blocker because it's a crash, it's a regression since Python 3.3 and it can be easily fixed (revert changes done in #19466). -- ___ Python tracker rep...@bugs.python.org

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

New submission from STINNER Victor: While trying to reproduce a race condition in asyncio, I got an assertion error from the Python garbage collector at exit. It's not easy to reproduce the issue: run attached script on Python 3.4 compiled in debug mode (to get assertions) and press CTRL+c

[issue20526] python: Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) != 0' failed.

Changes by STINNER Victor victor.stin...@gmail.com: Added file: http://bugs.python.org/file33939/asyncio_gc.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20526 ___