[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Thanks everyone for helping on the analysis and for reviews obviously. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

miss-islington added the comment: New changeset a78251e2d6de37f46c230be924032a87df730761 by Miss Islington (bot) in branch '3.7': bpo-35961: Fix a crash in slice_richcompare() (GH-11830) https://github.com/python/cpython/commit/a78251e2d6de37f46c230be924032a87df730761 -- nosy:

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: > This bug is 13 years old, I don't think that it's really useful to fix it. It > mostly impact test_slice and only test_slice. To be clear, I compiled Python 3.6 in release mode and applied test_slice patch of msg335333: no crash after 1500 runs. The bug

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Python 2.7 is not affected: it doesn't have the slice_richcompare() function, but the old slice_compare() implementation. Python 3.6 is affected but doesn't accept bugfixes anymore: https://devguide.python.org/#status-of-python-branches This bug is 13 years

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by miss-islington : -- pull_requests: +11869 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: New changeset dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae by Victor Stinner in branch 'master': bpo-35961: Fix a crash in slice_richcompare() (GH-11830) https://github.com/python/cpython/commit/dcb68f47f74b0cc8a1896d4a4c5a6b83c0bbeeae --

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: +1 on PR 11830 from me. Can always revisit if #11107 is ever implemented and it turns out that the reference count manipulation means startup is too slow due to all the slice interning triggered comparisons (unlikely, but theoretically possible I guess).

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: > Oh, Tim Peters succeded somehow to > remove Josh Rosenberg from the nosy list: I add him again ;-) Certainly wasn't my intent! That happens too often on the tracker. Thanks for noticing! :-( -- ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Oh, Tim Peters succeded somehow to remove Josh Rosenberg from the nosy list: I add him again ;-) Thanks Josh for your analysis, it seems like we agree :-) I wrote PR 11830 to use strong references, as you proposed. --

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: > Then again, there's probably no other code in the world that compares slice > objects ;-) Well, that's a good explanation :-) So maybe there is no need to keep the micro-optimization and PR 11830 would be safer (use strong references), rather than PR

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: Josh, I'd say the speed of this code doesn't matter one whit to anything. Like you, I'd _prefer_ that the issue be fixed by building "real tuples" that own their own references, which would also (as you showed) allow for briefer, simpler, clearer code. But

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I wrote PR 11830: the other solution that I propose, use strong references rather than borrowed references. -- ___ Python tracker ___

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- pull_requests: +11861 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: Ah, I see Victor posted an alternative PR that avoids the reference counting overhead by explicitly removing the temporary tuples from GC tracking. I'm mildly worried by that approach, only because the only documented use case for PyObject_GC_UnTrack is in

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Tim Peters added the comment: > It's impressive *and* scary that such 13 years old > bug only show up today... Then again, there's probably no other code in the world that compares slice objects ;-) -- nosy: +tim.peters -josh.r ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Josh Rosenberg added the comment: Victor found the same bug I found while I was composing this, posting only to incorporate proposed solution: I *think* I have a cause for this, but someone else with greater understanding of the cycle collector should check me if the suggested fix has

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: It's impressive *and* scary that such 13 years old bug only show up today... I modified the GC threshold in the site module with this patch: diff --git a/Lib/site.py b/Lib/site.py index ad1146332b..68cdf105b1 100644 --- a/Lib/site.py +++ b/Lib/site.py @@

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Extract of slice_richcompare(): t1 = PyTuple_New(3); if (t1 == NULL) return NULL; t2 = PyTuple_New(3); if (t2 == NULL) { Py_DECREF(t1); return NULL; } PyTuple_SET_ITEM(t1, 0, ((PySliceObject *)v)->start);

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- keywords: +patch pull_requests: +11859 stage: -> patch review ___ Python tracker ___ ___

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I removed Lukasz from the nosy list since it's not a regression. No need to spam our 3.8 release manager ;-) -- nosy: -lukasz.langa ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: It has been crashing for almost all the last 5 PRs merged to master : https://travis-ci.org/python/cpython/jobs/492241988 - Feb 12, 21:51 https://travis-ci.org/python/cpython/jobs/492123432 - Feb 12, 17:33

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: See also this idea of changing gc.set_threshold() when using -X dev: https://mail.python.org/pipermail/python-dev/2018-June/153857.html -- ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Ah! I found a way to reproduce the crash: diff --git a/Lib/test/test_slice.py b/Lib/test/test_slice.py index 4ae4142c60..b18f8f1c8c 100644 --- a/Lib/test/test_slice.py +++ b/Lib/test/test_slice.py @@ -1,4 +1,8 @@ # tests for slice objects; in particular the

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Karthikeyan Singaravelan added the comment: > Do you have an url to an example of crash on Travis? Travis crash that occurred few days back : https://travis-ci.org/python/cpython/jobs/491701299 . I first noticed it on an IDLE lib PR where this failure was unrelated but I can remember

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: On s390x Debian 3.x, it seems like the bug started to show up near: https://buildbot.python.org/all/#/builders/13/builds/2328 This build contains 2 changes, one doc change and this namedtuple change which mentions reference count:

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Lukasz: I'm not sure what is happening here, but such random bugs are always scrary. I raise the priority to "release blocker" until we know more about the issue. -- nosy: +lukasz.langa priority: normal -> release blocker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: Extract of the crashing test: def test_cmp(self): ... class Exc(Exception): pass class BadCmp(object): def __eq__(self, other): raise Exc s1 = slice(BadCmp()) s2 =

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: I'm unable to reproduce the issue on my Fedora 29 (x86-64) laptop. I used two terminals: * ./python -m test -F -j0 test_slice test_slice test_slice test_slice test_slice test_slice test_slice test_slice * ./python -m test -j0 -u all,-gui -r # stress the

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

STINNER Victor added the comment: > I am seeing some failures in travis and some buildbots: Do you have an url to an example of crash on Travis? Which buildbots are affected? I saw the crash on s390x Debian 3.x. -- ___ Python tracker

[issue35961] test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small

Change by STINNER Victor : -- title: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small -> test_slice: gc_decref: Assertion "gc_get_refs(g) > 0" failed: refcount is too small ___ Python tracker