[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

miss-islington added the comment: New changeset 50e847a9eb03f59e1d9268e46f3f98c2679caebd by Miss Islington (bot) in branch '3.9': bpo-40244: Remove XLC's support from the noreturn flag (GH-20588) https://github.com/python/cpython/commit/50e847a9eb03f59e1d9268e46f3f98c2679caebd --

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by miss-islington : -- pull_requests: +19822 pull_request: https://github.com/python/cpython/pull/20591 ___ Python tracker ___

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

miss-islington added the comment: New changeset 033d10bd21d962a59c6c4fc503092046baa451a1 by Batuhan Taskaya in branch 'master': bpo-40244: Remove XLC's support from the noreturn flag (GH-20588) https://github.com/python/cpython/commit/033d10bd21d962a59c6c4fc503092046baa451a1 --

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by Batuhan Taskaya : -- keywords: +patch pull_requests: +19821 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20588 ___ Python tracker ___

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > If you could prep a PR where the change is reverted - I would appreciate it. > If no time, I'll get to it as soon as I can. I see. I'll try to get a patch to deactivate it and add a comment (for future about this issue). --

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: I think this is showing up again. Ot seemed to be away when using xlcv13 (and is away with xlcv11). I switched my bot off of xlc (v13) because compile fails again - and I'll investigate manually using xlc again. If you could prep a PR where the change is

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: Any news about this? Should we revert the commit for 3.9? -- ___ Python tracker ___ ___

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: When I have more time I hope to investigate specifically what is different in the assembly code - with/without the __noreturn__ change. On 19/04/2020 08:20, Batuhan Taskaya wrote: > Batuhan Taskaya added the comment: > > Moving assertion from

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: Moving assertion from _PyObject_GC_TRACK to gen_dealloc (just before the _PyObject_GC_TRACK call) results with success () if (gen->gi_weakreflist != NULL) PyObject_ClearWeakRefs(self); - +_PyObject_ASSERT_FROM(self,

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > No. I do not think it is the real problem either. And I do not know compiler behavior well enough. Actually, considering the setting is still -O0 (aka no optimization) I am surprised it has any effect. if I understood correctly "no return" is intended to

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: On 14/04/2020 19:28, Michael Felt wrote: > Michael Felt added the comment: > > On 14/04/2020 14:54, Batuhan Taskaya wrote: >> Batuhan Taskaya added the comment: >> >>> With the print statements - it does not crash: >> I think this isn't directly relevant with

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: On 14/04/2020 14:54, Batuhan Taskaya wrote: > Batuhan Taskaya added the comment: > >> With the print statements - it does not crash: > I think this isn't directly relevant with prints but about re-compiling? > (just guessing). I only recompiled the one .c

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > Also tried this: Thanks for it, that was just something that I slightly suspected but expected to see it crash. -- ___ Python tracker

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: > With the print statements - it does not crash: I think this isn't directly relevant with prints but about re-compiling? (just guessing). Because I experienced when I compile python for the first time on a clean AIX environment, all extension modules

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: Also tried this: ./python -E -S -m sysconfig --generate-posix-vars ; if test $? -ne 0 ; then  echo "generate-posix-vars failed" ;  rm -f ./pybuilddir.txt ;  exit 1 ;  fi Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: With the print statements - it does not crash: ./python -E -S -m sysconfig --generate-posix-vars ; if test $? -ne 0 ; then  echo "generate-posix-vars failed" ;  rm -f ./pybuilddir.txt ;  exit 1 ;  fi Objects/genobject.c:122:537318120

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: By the noticed something that looks kind of weird, not sure if it is intentional or not but shouldn't this be self instead of gen static void gen_dealloc(PyGenObject *gen) { PyObject *self = (PyObject *) gen; _PyObject_GC_UNTRACK(gen); if

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: @Michael.Felt can you just insert some prints between these 3 to see what is going on (and re-compile) static void gen_dealloc(PyGenObject *gen) { PyObject *self = (PyObject *) gen; _PyObject_GC_UNTRACK(gen); if (gen->gi_weakreflist !=

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: After my build I have the following: $ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS' Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head *)(op)-1)->_gc_next != 0)" failed: object already tracked by the garbage collector Enable

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: Oh, looks like the problem is --without-computed-gotos, I just tried 2 times one is with --without-computed-gotos and one is not. I could successfully reproduce the problem with it. I'll continue triaging. --

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Batuhan Taskaya added the comment: I've just compiled python with (xlc 16.1.0, debug build) and can't experience that compile failure, can you give a specific spot that failure happens? -bash-4.4$ ./python -m test.pythoninfo|grep -E 'CFLAGS|CC|OPT|LDFLAGS' sysconfig[CC]:

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Change by Pablo Galindo Salgado : -- nosy: +BTaskaya, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

STINNER Victor added the comment: > [0003c2dc1d4cf5b122e73e83177fd274fa9a9913] bpo-40096: Support > __attribute__((__noreturn__)) on xlc (GH-19204) The fix looks simple: revert this change, no? -- ___ Python tracker

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: On 10/04/2020 14:01, STINNER Victor wrote: > STINNER Victor added the comment: > > The assertion failure occurs in _PyObject_GC_TRACK() at: > > static void > gen_dealloc(PyGenObject *gen) > { > PyObject *self = (PyObject *) gen; > >

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: It is only XLC-v16 that fails. XLC-v11 and XLC-v13 work fine. Am digging to see which version (< v16, or >= v16) is not working as expected. -- ___ Python tracker

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: After git bisect - comes down to: Bisecting: 0 revisions left to test after this (roughly 0 steps) [0003c2dc1d4cf5b122e73e83177fd274fa9a9913] bpo-40096: Support __attribute__((__noreturn__)) on xlc (GH-19204) --

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

STINNER Victor added the comment: The assertion failure occurs in _PyObject_GC_TRACK() at: static void gen_dealloc(PyGenObject *gen) { PyObject *self = (PyObject *) gen; _PyObject_GC_UNTRACK(gen); if (gen->gi_weakreflist != NULL) PyObject_ClearWeakRefs(self);

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Stefan Krah added the comment: Since I just had a similar incident with the Intel compiler, I just want to point out that compiling CPython still requires -fwrapv. I've mentioned this before in AIX issues, and no one has pointed out the corresponding xlc flag.

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

Michael Felt added the comment: dbx output: Again: help appreciated. (dbx) run -X tracemalloc Objects/genobject.c:127: _PyObject_GC_TRACK: Assertion "!(((PyGC_Head *)(op)-1)->_gc_next != 0)" failed: object already tracked by the garbage collector Enable tracemalloc to get the memory block

[issue40244] AIX: build: _PyObject_GC_TRACK Asstertion failure

New submission from Michael Felt : Calling this a compile error - as it seems to be compiler dependent. In other projects - when I have experienced issues as this it has been an uninitiated variable - somewhere. I would appreciate some suggestions on how to best debug this - as it seems to