Change by Michael Felt :
--
nosy: -Michael.Felt
___
Python tracker
<https://bugs.python.org/issue40170>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
I stopped running my bot. I have no idea if this is also an issue on 3.9+
And since noone will look at this in it's present state. I'd recommend closing.
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Michael Felt :
--
type: -> crash
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscrib
Michael Felt added the comment:
Dome some 'dumb' testing - and I hope this helps understand why it is failing:
With the the last two func() calls commented out, the function passes:
def test_output_string(self):
stdscr = self.stdscr
encoding = stdscr.encoding
Michael Felt added the comment:
Disregard the last mail -seems many routines go to unresolved.
On 15/08/2020 20:43, Stefan Krah wrote:
> Change by Stefan Krah :
>
>
> --
> assignee: -> skrah
> resolution: -> fixed
> stage: patch review -> resolved
&
Michael Felt added the comment:
Willing to spend more time on this - but the variable names chosen blind me -
looks like a circle.
And, thinking about the address in the core dump starting with 0xd (segment 13)
- confuses me somewhat - as from memory - I thought the shared library
code
Michael Felt added the comment:
OK. Please explain. Looking at tstate assignment
In posixmodule.c:PyOSAfterFork_Child()
PyStatus status;
_PyRuntimeState *runtime = &_PyRuntime;
...
PyThreadState *tstate = _PyThreadState_GET();
and later calls
st
Michael Felt added the comment:
OK: further.
Two options are suggested:
There are different options to solve this issue:
* Reset _tstate_lock before using it... not sure that it's worth it, since we
are going to delete the threading.Thread object with its _tstate_lock object
anymore
Michael Felt added the comment:
Adding 3.10.
While a (sort of) duplicate I also would like to add that before revision
"7cb033c423b65def1632d6c3c747111543b342a2" this was not showing up as an issue
with test_importlib.
my issue was with test_importlib suddenly going
Michael Felt added the comment:
On 31/03/2021 18:46, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import
>
> This test comes from bpo-41567 and it simply runs a scri
Michael Felt added the comment:
Sure. Probably have to rebase first.
--
___
Python tracker
<https://bugs.python.org/issue28276>
___
___
Python-bugs-list mailin
Michael Felt added the comment:
On 30/03/2021 09:40, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> A core dump is a very bad sign of health.
>
> Can you please try to bisect which test is causing the segfault using
> bisect_cmd? Try the command:
>
> ./p
Michael Felt added the comment:
FYI: from a core dump - top of where is:
Segmentation fault in winsnstr at 0xd3ebc050
0xd3ebc050 (winsnstr+0x190) a4190002 lhzu r0,0x2(r25)
(dbx) where
winsnstr(??, ??, ??) at 0xd3ebc050
unnamed block in IPRA.$_curses_window_insstr_impl(self
Change by Michael Felt :
--
keywords: +patch
pull_requests: +23845
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25095
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
./python -m test -vuall -i test_output_string -i test_insert_delete test_curses
2>test.err 1>test.out
returns four failures: see attached
'-i test_output_string' stops the crash
--
Added file: https://bugs.python.org/file49918/te
New submission from Michael Felt :
When working in a WPAR (workload partition) the routines supporting
aix_platform() may fail if there is no related builddate for bos.mp64.
a) the fileset queried is changed to `bos.rte`
b) an extreme value (9988) is returned for any similar (unexpected
New submission from Michael Felt :
Since issue43517 test_importlib 'fails' (bot status) with ENV_CHANGED.
The core dump is caused by SIGTRAP. I need help to learn how to stop the core
dump from being cleaned up so I can load it into dbx and hopefully
understand/learn with sub-test
Michael Felt added the comment:
my default TERM=xterm
I'll also use 'ansi'
The filenames will be ${TERM}.err and ${TERM}.out
for TERM in xterm ansi; do
./python -m test -vuall test_curses 2>${TERM}.err >${TERM}.out
done
After TERM=ansi - my terminal is in raw mode (i.e.,
$ stty s
Michael Felt added the comment:
backports needed for 3.8 and 3.9
--
versions: +Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue43
Change by Michael Felt :
--
keywords: +patch
pull_requests: +23824
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25074
___
Python tracker
<https://bugs.python.org/issu
New submission from Michael Felt :
Since issue42789 the AIX bot's have crashed - to the extent that the bot's did
not even return results.
Part of this has been resolved, for now, by using:
$ export TERM=unknown
$ buildbot start buildarea
However, the test still crash because AIX default
Michael Felt added the comment:
OK - looking at this again.
This looks very similiar to another 'coredump' issue (will have to look for the
number later). iirc, when something called 'pgen', or similiar was modified.
Here is a lengthy `dbx` dump.
If I am reading this correctly
Michael Felt added the comment:
While my patch in working - was successful in what it attempted to do, it did
not fix this test issue.
Instead - I reinstalled the `bos.adt.libm-7.2.0.0` fileset, to backout of the
so-called bugfix/APAR IV95512.
@David - can you take this up with AIX support
Michael Felt added the comment:
I have been doing a lot of research on this. Wish I had thought do start the
way I finished.
Basically, when math.nextafter() was added all the AIX bots were on systems
running AIX earlier than AIX 7.2 TL2.
When AIX 7.2 TL2 was released (roughly Q3 2017
Michael Felt added the comment:
The 'issue' is that a package known as autoconf-archive must ALSO be installed
- so that aclocal has a definition for ax_check_compile_flag.
Guessing that resolution is `third_party` - If not, please explain what the
resolution flag is used
Michael Felt added the comment:
This is beginning to look like it is an issue with the version of automake
installed:
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]automake --version
Unescaped left brace in regex is deprecated, passed through in regex; marked by
<-- HERE i
Michael Felt added the comment:
This is what I find via bisect:
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git checkout . && git
bisect bad
c6d7e82d19c091af698d4e4b3623648e259843e3 is the first bad commit
commit c6d7e82d19c091af698d4e4b3623648e259843e3
Author: Petr Viktor
New submission from Michael Felt :
While working on a PR for issue42323 I get an error with the generated
./configure even without my patch.
Working from commit 37a6d5f8027f969418fe53d0a73a21003a8e370d
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git log --oneline | head
37a6d5f
Michael Felt added the comment:
Sorry Victor - family matters - so I was not watching for several days.
--
___
Python tracker
<https://bugs.python.org/issue41
Michael Felt added the comment:
Looking at https://github.com/python/cpython/pull/22088/files
imho: the patch forced Windows behavior ("""Initialize the module as
appropriate for NT""") to be equivalent to vars['SO'] - which is what the test
used to c
Michael Felt added the comment:
On Windows - in distutils (?) did they perhaps make a change only for windows,
for whatever reason.
I don't have a python3.7 pr a 3.8 handy atm.
Not sure what 'distutils' pip updates either - but with py36 and pip 20.2.4 and
setuptools 40.6.2 I get:
Python
Michael Felt added the comment:
This is still broken.
Since this was included in master - the AIX buildbot is failing to compile
(https://buildbot.python.org/all/#/builders/438/builds/391 and
https://buildbot.python.org/all/#/builders/302/builds/377)
Strangely enough - the first bot
Michael Felt added the comment:
Yes, just probing, the version of gcc is irrelevant.
What I do believe is important is that bot run 374, 375 and 376 passed - On AIX
7.1 TL4 SP8.
The failure starting with 377 is an undefined variable.
"./Modules/posixmodule.c", line 15146.53: 1
Michael Felt added the comment:
There seems to be a lot of interaction of OS level and compiler used.
* Waiting for the next bot run to get a different compiler.
+++
AIX 6.1.6 and older libraries - no test errors reported
AIX 7.1.4 and newer libraries - when using the binary built on 6.1.6
Michael Felt added the comment:
For now, I am going to suggest closing this - as a bug in the xlc-v11 compiler
- and not worth researching.
I am able to build the 3.9 distribution as well as the 3.10 master using the
xlC-v13-1.3.2 (Try and Buy) version.
Thanks for thinking together
Michael Felt added the comment:
I have been experimenting with different hardware and AIX versions.
When building on AIX 5.3 - and the oldest libraries - test_math passes.
When I run the test on POWER8, using either xlc or gcc test_math fails with
just one element of the test.
When I run
Michael Felt added the comment:
Added "using xlc" to description.
When I have a system that has 64-bit support for gcc - I'll verify that it
works, or does not work, for me using gcc.
--
title: BUILD: AIX-64-bit segmentation fault -> BUILD: AIX-64-bit segmentation
fa
Michael Felt added the comment:
On a different server, different compiler (xlc-v13, mine is xlc-v11) it gets
past this point.
So, perhaps it is a compiler issue.
As the second system is missing many 64-bit libraries - still cannot build
64-bit Python-3.9.
Low priority - imho
New submission from Michael Felt :
Successfully built and packaged the Python-3.9.0 distribution tar archive
without modification - as 32-bit.
Repeating the same process with the following environment change:
# export OBJECT_MODE=64
fails with a segmentation fault by the "first-
Michael Felt added the comment:
As much as I wish I had the skills to do the cherry picking - I am not going to
touch this.
The AIX bots for 3.9 branch continue to report broken for test_io (ENV change)
- as they still wait for the backport for that branch
Michael Felt added the comment:
If #19521 had been merged I would be all for closing this as a duplicate.
However, if i have read all the comments correctly noone has tested the other
pr.
As the approaches are quite different I think both should be open until a
decision is made
New submission from Michael Felt :
Two tests in test_pathlib test that the files created have mode o666 (rw-rw-rw).
However, on a filesystem (in my case NFS) configured to never permit global
write - the test will always fail.
Is this something to be concerned about?
I can think of a few
Michael Felt added the comment:
The 'master' branch bot is working again, the 3.9 branch is still broken, and
the 3.8 branch seems, as yet, unaffected.
--
___
Python tracker
<https://bugs.python.org/issue41
Michael Felt added the comment:
Excellent!!
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git pr 21640
remote: Enumerating objects: 50, done.
remote: Counting objects: 100% (50/50), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 58 (delta 46), reused 48 (delta 46
Change by Michael Felt :
--
keywords: +patch
pull_requests: +20780
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/21639
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
Thanks. afaik, double spacing is a 'feature' a programmer added to a
text processing language - of the WYSIWUG kind, because program's such
as troff/nroff
didn't need them. They, rather it, understood that a period followed by
a space indicated the end
Michael Felt added the comment:
Neat! extra arguments!!
The warnings - extracted:
== CPython 3.10.0a0 (heads/master-dirty:b1a8730, Jul 26 2020, 14:00:34) [GCC
7.2.0]
== AIX-2-00F9C1964C00-powerpc-32bit big-endian
== cwd: /home/aixtools/cpython/cpython-master/build/test_python_27984450
Michael Felt added the comment:
I am taking a look at these, and I am sure there is a PEP I am unaware of - atm
- so, a quick question.
Is the double space at the end of a sentence 'required' by the rst processing,
or is this also a 'personal' writing style in some of the documents (i.e
New submission from Michael Felt :
issue41069 introduces tests for paths/files containing non-ascii characters.
On AIX - since the merge of PR21035 and PR21156 - the bots have been broken,
i.e., returning test failed.
commit 700cfa8c90a90016638bac13c4efd03786b2b2a0
Author: Serhiy Storchaka
Michael Felt added the comment:
Here is the stack trace - still during initialization: And in "ceval.c,
but dbx does not like how the 'h files are being used: line 941 and 659
lines don't match :(
(dbx) list
"object.h" has only 659 lines
Segmentation fault in _PyEval_EvalFrame
Michael Felt added the comment:
On 07/07/2020 11:12, Michael Felt wrote:
> Michael Felt added the comment:
>
> I saw the mails last night and restarted my bot - it still fails.
> Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
3.7, 3.8 and 3.9 built,
Michael Felt added the comment:
I saw the mails last night and restarted my bot - it still fails.
Checking manually for master, 3.9, 3.8 and 3.7 branches. Will let you
know asap.
Yes - expecting 3.8 and 3.7 to build, but want to be sure.
On 06/07/2020 23:34, Pablo Galindo Salgado wrote
Michael Felt added the comment:
I also tested xlC v16, and then it just hung, for hours - while all of you were
being more productive.
I’ll kickoff my bot again, and see how it goes.
Sent from my iPhone
> On 6 Jul 2020, at 21:31, miss-islington wrote:
>
>
> miss-isli
Michael Felt added the comment:
Note: - two different systems, different HW, different OS levels.
xlc-v11, master : commit deb016224cc506503fb05e821a60158c83918ed4 (HEAD
-> master, upstream/master, upstream/HEAD)
Segmentation fault in _PyEval_EvalFrameDefault at line 941 in file
"../
Michael Felt added the comment:
I tried check.c and check_bad.c using xlc-v11 (on my POWER6) - and the
results were the same as in Pablo's entry.
On the gcc119 host - using the v13 compiler, check_bad does not crash.
Not gotten to testing xlc-v16 yet.
I have seen lots of options today
Michael Felt added the comment:
On 06/07/2020 16:35, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
>> Glad you figured it out!
> Well, this is not over ;)
>
> We should confirm that this is either a bug in XLC or a violation of C99
probably a
Michael Felt added the comment:
Glad you figured it out!
I doubt I would have. Thx!!
On 06/07/2020 14:37, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> This is enough to reproduce the problem:
>
> #include
>
> typedef struct {
> c
Michael Felt added the comment:
Thanks for getting back to this. ++1 :)
On 25/06/2020 11:49, Serhiy Storchaka wrote:
> Serhiy Storchaka added the comment:
>
> test_bdb fails on non-UTF-8 locale because Python executes a Python code from
> the corresponding "enc
Michael Felt added the comment:
My apologies for lack of context.
On 05/07/2020 20:27, Pablo Galindo Salgado wrote:
> Pablo Galindo Salgado added the comment:
>
> Unfortunately, I am having a hard time parsing your error description because
> is not immediate to distinguish
Michael Felt added the comment:
Iirc, my debug shows that k is not NULL, as k++ is not going to suddenly become
smaller. And my debug shows it grows by a constant.
My gut says the pointer to the base of the tokens is wrong, because the key
types are such different values. Or do you know
Michael Felt added the comment:
Thanks Kevin.
I took your patch (added your name to blurb as well).
Only difference was to remove Qsystem (or something), from the pathnames.
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.
Michael Felt added the comment:
OK - merely added some fprintf statements.
When it is working as expected, the k->type values seem to be between 500 and
535 - when it fails the k->type value is frequently 9 digits (e.g., 537120904)
- and it seems to never become -1 -- which wou
Michael Felt added the comment:
Well, the first step -s just showing where the segmentation fault occurs (in
pegen.c).
I am not really 'wiser' in what I should be looking at. I'll try adding a
fprintf(stderr, ) to see if I can figure out a bit more.
For the experts:
(dbx) where
New submission from Michael Felt :
As the bots were both running - based on gcc - this was not noticed immediately.
issue40334 implements PEP 617, the new PEG parser for CPython.
Using bisect I located:
commit c5fc15685202cda73f7c3f5c6f299b0945f58508 (HEAD, refs/bisect/bad)
Author: Pablo
Michael Felt added the comment:
I have been doing manual tests - and it seems build is broken for AIX
and xlc.
I shall be working on a git bisect to try and identify what broke it for
xlc-v11. Finding what broke xlc-v13 will require more time.
Note: it is no longer limited to _decimal
Michael Felt added the comment:
There is still a lot of AIX 6.1 out there, and iirc, there may be
"extended" support available.
However, at this point in time the bots run (most of the time) on AIX
7.2, -- occasionally, on AIX 7.1. And when I (personally) test - it is
usually on AI
Michael Felt added the comment:
I switched the "aixtools" bot back to "xlc", and also back to my POWER6
server that runs xlc-v11.
iirc it is xlc-v13 (or maybe even v12) that is having trouble with
_decimal (or is it POWER8). From memory, _decimal was compiling properly
wit
Michael Felt added the comment:
I’ll switch back to xlc ( even try without the _r ) and look for the macro asap
(vacation and occasional travel).
Sent from my iPhone
> On 15 Jun 2020, at 21:20, Stefan Krah wrote:
>
>
> Stefan Krah added the comment:
>
> Thanks!
>
Michael Felt added the comment:
I'll switch my bot https://buildbot.python.org/all/#/builders/119 to use
c99_r rather than xlc_r.
Test 1129 will b e the first with c99_r (and xlc v13).
On 11/06/2020 00:37, Stefan Krah wrote:
> Stefan Krah added the comment:
>
> So it wo
Michael Felt added the comment:
Yes, it is less hacky - and something to pursue later - as a better
solution. Even the idea of perhaps no longer needing makexp_aix and/or
ld_so_aix and python.exp is much better solution.
However, the goal of this PR is to have something now - that removes
Change by Michael Felt :
--
title: AIX: parallel build and ld WARNINGS -> AIX: makexp_aix, parallel build
(failures) and ld WARNINGS
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
specifically, makexp_aix - from 1998-1999 - did not consider parallelization.
make -j2 is sufficient to create the following issue - that frequently leads to
a failed compile/build.
./Modules/makexp_aix Modules/python.exp . libpython3.9d.a; gcc -pthread
Michael Felt added the comment:
No, it is not supported - asin there are no new patches - but there are
organizations that use it.
imho - those organizations are not likely to be using the latest Python
- but I have been packaging Python on AIX 5.3 and AIX 6.1 - as these
packages run
Michael Felt added the comment:
Actually, iirc - xlc is c99 plus a few extra settings.
The configuration files for xlc are, traditionally, in /etc (the later
versions of the compiler have moved them into /opt/show/where so that
multiple versions of the compiler can be installed.
buildbot@x064
Michael Felt added the comment:
The 'fancy' file name breaks on latin-1 character set.
aixtools@gcc119:[/home/aixtools/python/py39-3.9]
a4fa9a95153a3800dea60b3029b2dcaf8a4f6acb Lib/test/test_importlib/test_main.py
<
diff --git a/Lib/test/test_importlib/test_main.py
b/
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
New submission from Michael Felt :
issue40192 introduced the use of nanosecond reporting of time.
The new routine called is not available in AIX 5.3:
xlc_r -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O
-I../git/python-3.9/Include/internal -IObjects -IInclude -IPython -I.
-I
Michael Felt added the comment:
I could not "fathom" the buildbot test results - however, a manual build of
PR29170 on 3.9 works: I'll try 3.8, but then from master (assuming it is
already part of master) -- and that works as well.
Thanks for the qu
Michael Felt added the comment:
Bot failed for AIX https://buildbot.python.org/all/#builders/227/builds/978
with:
0:07:11 Re-running test_asyncio in verbose mode
Failed to import test module: test.test_asyncio.test_events
Traceback (most recent call last):
File
"/home/shager/cp
Change by Michael Felt :
--
keywords: +patch
pull_requests: +19081
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19759
___
Python tracker
<https://bugs.python.org/issu
New submission from Michael Felt :
Currently, on AIX, whenever the -j option is passed to make there are many
WARNINGS from the loader (ld) re: duplicate symbols.
While it is not possible to eliminate these warnings completely - as some are
not related to the Python build, but external (3rd
Michael Felt added the comment:
Thanks for the quick response. I see both bots are good.
--
___
Python tracker
<https://bugs.python.org/issue40370>
___
___
Pytho
Michael Felt added the comment:
Thanks for the quick work. I’ll test with xlc as well, as the builds behave
differently this afternoon.
Sent from my iPhone
> On 23 Apr 2020, at 16:31, Pablo Galindo Salgado
> wrote:
>
>
> Pablo Galindo Salgado added the comment:
>
Michael Felt added the comment:
More `make test` output:
1 test failed:
test_peg_generator
18 tests skipped:
test_devpoll test_epoll test_gdb test_ioctl test_kqueue
test_msilib test_ossaudiodev test_spwd test_startfile test_tix
test_tk test_ttk_guionly test_unicode_file
Michael Felt added the comment:
with the xlc-v11 environment yet another issue:
Stop.
/usr/bin/make returned an error
root@x065:[/data/prj/python/python-3.9]make V=1
xlc_r -c -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O
-I../git/python-3.9/Include/internal -IObjects
Michael Felt added the comment:
Currently build using xlc-v13 hangs during creation of _json.so. Trying xlc-v11.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
New issue with test during PR19764:
0:03:29 [416/423/1] test_peg_generator failed (2 min 34 sec) -- running:
test_pathlib (3 min 19 sec), test_bufio (3 min 17 sec), test_concurrent_futures
(3 min 10 sec), test_multiprocessing_fork (3 min), test_subprocess (2
New submission from Michael Felt :
As part, I assume, of PR19503, that includes 91 changed files with 27,058
additions and 147 deletions the AIX buildbot is broken.
Rather than looking/finding Modules/ld_so_aix (where I expect it to be) tests
are failing, ulitmately because they look/expect
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 asser
Michael Felt added the comment:
Checked with latest version - and working as expected. Sorry for the noise.
On 15/04/2020 17:53, SilentGhost wrote:
> SilentGhost added the comment:
>
> Michael, could you try with the latest fix in 584a3cfda4?
>
> --
>
Michael Felt added the comment:
I did update, and saw that there was one more patch applied.
I think that fixed the define issues, but there may be a new concern. Ran out
of time to document it today.
Will post tomorrow.
Sent from my iPhone
> On 15 Apr 2020, at 17:53, SilentGhost wr
Michael Felt added the comment:
And when I use a standard OpenSSL library (on AIX):
building '_ssl' extension
gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -std=c99 -Wextra
-Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers
-Werror=implicit-function
Michael Felt added the comment:
Also checking with gcc: get the following messages:
Failed to build these modules:
_ssl
Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with
X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide
Michael Felt added the comment:
Do I need to open a new issue?
This breaks building _ssl on AIX.
building '_ssl' extension
xlc_r -O -I./Include/internal -I/opt/aixtools/include -I./Include -I.
-I/home/aixtools/python/cpython-master/Include
-I/home/aixtools/python/cpython-master -c
/home
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:
>>
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 rec
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 "!(((PyG
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
Objects/g
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
col
Michael Felt added the comment:
Thank you!
On 09/04/2020 17:33, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> I backported the fix to 3.8 to fix AIX 3.8 buildbots.
>
> --
>
> ___
> Python tracker
&g
1 - 100 of 737 matches
Mail list logo
