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;
>
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
<https://bugs.python.org/i
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
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
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
Michael Felt added the comment:
Yes, looks like I need to find that. thx for the reminder.
--
___
Python tracker
<https://bugs.python.org/issue37009>
___
___
Michael Felt added the comment:
requesting backport of PR19225.
After switching my bot to xlc-v13 it fails this test.
See botstatus mail excerpt:
The Buildbot has detected a failed build on builder POWER6 AIX 3.8 while
building python/cpython.
Full details are available at:
https
Michael Felt added the comment:
Just checked - seems to be SPECIFIC to xlc-v16 as neither xlv-v11 nor xlc-v13
have any issues building.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
Just manually verified that PR19377, when compiled against xlc - crashes during
make:
rm -f libpython3.9d.a
ar rcs libpython3.9d.a Modules/getbuildinfo.o Parser/acceler.o
Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o
Michael Felt added the comment:
Thanks for the fix!
--
___
Python tracker
<https://bugs.python.org/issue40155>
___
___
Python-bugs-list mailing list
Unsub
Change by Michael Felt :
--
keywords: +patch
pull_requests: +18671
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19308
___
Python tracker
<https://bugs.python.org/issu
Change by Michael Felt :
--
pull_requests: +18670
pull_request: https://github.com/python/cpython/pull/19308
___
Python tracker
<https://bugs.python.org/issue31
Michael Felt added the comment:
To get it to move forward: as it is not solely and AIX thing (see bpo-40-140)
This works: but is it what is wanted?
Tests result: SUCCESS
aixtools@x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index
Michael Felt added the comment:
FYI: in child block:
calling os.exit(0), rather than os._exit() gives same result.
--
___
Python tracker
<https://bugs.python.org/issue40
Michael Felt added the comment:
Next debug info:
I am child - this is my PID:8519830
I am parent:18284612 with child:8519830fd:6 input:b'quux\r'
I am parent:18284612 with lines:[]
I am child - exiting PID:8519830
I am parent:18284612 with lines:['stdin.isatty(): True']
I am parent:18284612
Michael Felt added the comment:
I tried moving the child/parent logic blocks and get this as debug output:
aixtools@x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin
I am child - this is my PID:8519822
I am parent:6422696
Michael Felt added the comment:
If I move the close to before the support.waitprocess() call I get:
aixtools@x064:[/home/aixtools/py39-3.9]./python -m test test_builtin
0:00:00 Run tests sequentially
0:00:00 [1/1] test_builtin
I am child - this is my PID:2254
I am parent:21954666
Michael Felt added the comment:
Now consistently - stalled.
aixtools@x064:[/home/aixtools/py39-3.9]git diff
diff --git a/Lib/test/test_builtin.py b/Lib/test/test_builtin.py
index eaada1b504..89c4ebc2bd 100644
--- a/Lib/test/test_builtin.py
+++ b/Lib/test/test_builtin.py
@@ -1849,26 +1849,40
Michael Felt added the comment:
did not get issue numbers in above: issue31160 and issue40094.
I waited a day, before posting - in the hope it would go away.
Also, I have been testing manually (no -j arguments) - and test_builtin passes
when run manually. So, becoming hard to dissect
New submission from Michael Felt :
related to
Two AIX bots - different environments - continue to fail the test:
`test_builtin` since
During the first run - the test fails with something such as:
0:31:47 [215/420] test_abc passed -- running: test_builtin (14 min 10 sec)
0:32:17 running
Michael Felt added the comment:
I think something is not yet what it needs to be:
the bots both finish test with:
test_zip_pickle (test.test_builtin.BuiltinTest) ... ok
Timeout (0:15:00)!
Thread 0x0001 (most recent call first):
File
"/home/buildbot/buildarea/3.x.aixtools-aix-p
Michael Felt added the comment:
Ah - great. Sorry for the noise then.
--
___
Python tracker
<https://bugs.python.org/issue31160>
___
___
Python-bugs-list mailin
Michael Felt added the comment:
With PR19263 The AIX bots are now red.
==
ERROR: test_input_no_stdout_fileno (test.test_builtin.PtyTests)
--
Traceback (most
Change by Michael Felt :
--
keywords: +patch
pull_requests: +18587
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19225
___
Python tracker
<https://bugs.python.org/issu
New submission from Michael Felt :
The is a check if compiler is xlc, and skips a test if it is.
XLC no longer installs in /usr/vac, and the test_search_cpp fails (again)
--
components: Distutils
messages: 365302
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity
Michael Felt added the comment:
FYI: IMHO it is artifact of the way an xlc compiler is setup. Maybe this is a
new default (I see they changed the names of config files).
On my server (with xlc v11) I do not get them, but on a different server (with
xlc v13) I do get .lst files.
So, seems
Michael Felt added the comment:
Back again - I understood a lot less then, maybe more now..
iirc, get_platform() asin sysconfig.get_platform() and
distutils.util.get_platform() are suppposed to return a suitable PEP425 tag
that identifies the ABI of the running interpreter - eg.g, 32-bit
Michael Felt added the comment:
I see that it is also incorrect for v3.5.9
What is surprising - is that the logic is okay for python-config ->
python-config3.X -> python-config-3.Xm
root@x065:[/data/prj/python/python3-3.5.9/X32]ls -l opt/bin
total 8728
lrwxrwxrwx 1 root
Change by Michael Felt :
--
versions: +Python 3.5
___
Python tracker
<https://bugs.python.org/issue40073>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
I tried looking at the blurbs to get an idea of what might have been the change
- but nothing to indicate a change to the install process in any of "next" NEWS
blurbs that are currently in branch 3.7
NEWS.d/next/Build/README.rst
NEWS.d/next/C API/
New submission from Michael Felt :
This is a regression in v3.6.10 and v3.7.6
`make install` creates a symbolic link `python3` that points to the executable
python3.X
In versions v3.6.10 and v3.7.6 the executable is created as python3.Xm while
the symbolic link still points to python3.X
Michael Felt added the comment:
My apologies for the late reply -
Here is 3.6.10:
Python 3.6.10 (default, Mar 24 2020, 14:12:31) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> tim
Michael Felt added the comment:
the XLC compiler has an option to create "listing" files. The content depends
on the arguments passed to the xlc compilers.
>From memory (as I always need to look them up) these include -qinfo and
>-qsource (plus arguments)
FYI: besi
Michael Felt added the comment:
@BTaskaya - can you elaborate on what issues you ran into? Perhaps open an
issue on the repository I started to work on getting this improved.
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
On 18/03/2020 13:55, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> I may be mistaken, but I do not think the change introduced a regression.
I meant - I had never considered IPv6 in the Address column, just as I
suspect, w
Michael Felt added the comment:
I may be mistaken, but I do not think the change introduced a regression.
While it is true that this case would not have appeared if there was
still a count of the field-separators an IPv6 address with 5 ':' and 17
characters would have failed as well
Michael Felt added the comment:
I'll take a look as well.
On 17/03/2020 16:14, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> New changeset 0bcbfa43d55d9558cdcb256d8998366281322080 by Tal Einat (Michael
>> Felt) in branch 'master':
>> b
Michael Felt added the comment:
Fantastic! Many thanks!
--
___
Python tracker
<https://bugs.python.org/issue39936>
___
___
Python-bugs-list mailing list
Unsub
Michael Felt added the comment:
The good news! Your patch, better rewrite, of _aix_platform.py is working!
Many thanks!
--
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
re: Michael: this issue is about bootstraping Python. If you want to test a
patch or test something else, you must restart from a clean copy of the source
code. Either use "make distclean", "git clean -fdx", or recreate the source
Michael Felt added the comment:
Actually, I had already done that:
diff --git a/Lib/_aix_support.py b/Lib/_aix_support.py
index 2c5cd3297d..c7f4491633 100644
--- a/Lib/_aix_support.py
+++ b/Lib/_aix_support.py
@@ -12,7 +12,8 @@ try:
_tmp_bd = get_config_var("AIX_BUILDDATE")
Michael Felt added the comment:
OK. I removed the _aix_support.py from the formula.
After make see the new (rather) old build paths for "socket"
aixtools@x064:[/home/aixtools/python-3.9]find . | grep socket
./Doc/howto/sockets.rst
./Doc/library/socket.rst
./Doc/library/socketserver
Change by Michael Felt :
Added file: https://bugs.python.org/file48971/make.log
___
Python tracker
<https://bugs.python.org/issue39936>
___
___
Python-bugs-list mailin
Michael Felt added the comment:
So, this is what I have on screen. Will add the log in a moment.
[1] + Donemake 2>&1|tee make.log &
aixtools@x064:[/home/aixtools/python-3.9]find . | grep socket
./Doc/howto/sockets.rst
./Doc/library/socket.rst
./
Michael Felt added the comment:
So, with the patch - the process stops at:
aixtools@x064:[/home/aixtools/python-3.9]make
CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp'
OPT='-DNDEBUG -O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py
build
Traceback
Michael Felt added the comment:
I'll take a look at what you are suggesting.
The starting point (before the rm command) is the make command that I run again.
What I notice - read am thinking - is that _socket.so is being created by the
"setup.py build" - so, if you can help me mak
Michael Felt added the comment:
While looking through the history of bot builds - I consistently see 420 tests
being done on one bot - but test_socket does not always show up in the list.
I'll look at this as I can, but "free-time" is limited. Delay is not a lack of
Michael Felt added the comment:
After a checkout the build finishes (successfully) with:
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_gdbm _lzma _sqlite3
_tkinter _uuid
Michael Felt added the comment:
This was already confirmed by both bots...
The last bot build that worked (and for both AIX bots) is:
dffe4c07095e0c693e094d3c140e85a68bd8128e
The first build that failed (for both) is:
1ec63b62035e73111e204a0e03b83503e1c58f2e
See (pass) https
Michael Felt added the comment:
I am confused.
The bot complains nearly immediately about missing _socket
Following modules built successfully but were removed because they could not be
imported:
_asyncio
running build_scripts
copying
Michael Felt added the comment:
OK. BEFORE I open a new issue, I am going to guess that something is wrong with
finding _socket.so - because it exists, but "something" is not finding it.
Following modules built successfully but were removed because they could not be
imported:^
Michael Felt added the comment:
re: _socket - I'll start researching now, but it may still be related to this.
a) if it looks like related to this issue I'll add a some report here
b) in any case, as requested, I'll start a new issue - and leave it to you to
decide to close that and continue
Michael Felt added the comment:
Comes further. The build finishes, but socket and asyncio are missing...
At least a build will proceed, and I can look into this new, perhaps unrelated
issue re: socket later.
*** WARNING: renaming "_asyncio" since importing it failed: No mo
Michael Felt added the comment:
Almost. The command is run, but not enough of the bootstrap is finished - it
seems.
File "/data/prj/python/git/python3-3.9/Lib/_aix_support.py", line 54, in
_aix_bosmp64
out = out.decode("utf-8").strip().split(":") # typ
Michael Felt added the comment:
Thanks for asking!
Last December I was thinking about this - and what would be the best way to
proceed.
The reply I liked best suggested working on this - outside of CPython
"bugfixes" - perhaps later moving bits into the core.
So, motivat
Change by Michael Felt :
--
pull_requests: +18204
pull_request: https://github.com/python/cpython/pull/18847
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
The PR for 3.9 breaks AIX build (since
https://buildbot.python.org/all/#/builders/119/builds/384) reporting the
following:
Traceback (most recent call last):
File "/data/prj/python/python3-3.9/../git/python3-3.9/setup.py", line 69, in
Michael Felt added the comment:
This issue was resolved by issue39802. Marking as fixed, and closed.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Michael Felt :
--
pull_requests: +18078
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18720
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
I am very busy with normal work this week. However I’ll attempt to add a pr
with your (Victor”s) suggestion.
Sent from my iPhone
> On 29 Feb 2020, at 23:36, STINNER Victor wrote:
>
>
> STINNER Victor added the comment:
>
>> Fil
Michael Felt added the comment:
PR18517 has, likely, a utf-8 dependency. AIX, default latin-1 does not accept
the new test.
Starting with this merge AIX bot fails with:
==
ERROR: test_name_resolution
Michael Felt added the comment:
FYI: I was contacted this week by someone with this problem.
The problem was resolved after they updated AIX (was 7100-04-00-).
Please note: any oslevel -s reporting six zeros at the end needs the SP that is
released in parallel with the base
Michael Felt added the comment:
OK. Couple of months later.
Would appreciate guidance before submitting a patch.
In advance: Thank you for your time and consideration.
Short: socket.sendfile() and AIX send_file() are very close in terms of
functionality - especially the requirement
Michael Felt added the comment:
Not sure I understand what bug I am supposed to report. I apologize if
my message https://bugs.python.org/issue39502#msg361116.
I assume your comment re: time.localtime(91301504) comes from this bit
of the test message (mtime_ns=913015040).
Assuming
Michael Felt added the comment:
closing. Will open a new issue with a correct description of the issue at hand.
The problem is related to 64-bit mode (which was not mentioned before) and
minor() major() macro definitions.
--
stage: -> resolved
status: open ->
Michael Felt added the comment:
Not an issue in 3.9, so, closing: "not relevant"
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.py
Michael Felt added the comment:
Closing, as not longer relevant.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Change by Michael Felt :
--
keywords: +patch
pull_requests: +17689
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18313
___
Python tracker
<https://bugs.python.org/issu
Change by Michael Felt :
--
versions: +Python 3.8, Python 3.9 -Python 2.7
___
Python tracker
<https://bugs.python.org/issue28276>
___
___
Python-bugs-list mailin
Change by Michael Felt :
--
keywords: +patch
pull_requests: +17688
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18312
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
This is something from long long ago - time to get it completed.
The (remaining) issue is: "c" and "m" may not be shared libraries - so nothing
is ever found and the test is "skipped" but reports itself as PASSED.
The
Michael Felt added the comment:
Blinded - got the numbers wrong!
So, again: Thanks for PR 18302. I followed your lead and made the additional
changes and posted as PR 18303 in the hope this is easier for all.
--
___
Python tracker
<ht
Michael Felt added the comment:
Thanks again for PR 18202. I followed your lead and made the additional changes
and posted as PR 18203.
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Michael Felt :
--
pull_requests: +17680
pull_request: https://github.com/python/cpython/pull/18303
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
Here is the patch I am working on.
I appreciate your example on how to deal with the undefined variables. I had
done that incorrectly initially.
--
Added file: https://bugs.python.org/file48876/bpo-39020-AIX.patch
Michael Felt added the comment:
Have looked at your PR. It will not work on AIX because AIX libcurses is
missing all four new functions.
Once I finished my test on AIX - shall I add my patch as a file here, so you
can integrate into yours?
I hope that is easier than two PRs
Michael Felt added the comment:
removed 3.8, this is new for 3.9.
Have established that all four functions added in issue38132 do not exist in
stock AIX libcurses.a
Was working on my own PR, but shall look at yours first.
--
versions: -Python 3.8
Michael Felt added the comment:
Adding 3.8 before I post a PR - as I think the initial merge that introduced
the regression was before master was considered 3.9.
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
p.s., I manually added #18282 to the test, and the results are the same as
without - using 64-bit. Will rebuild the 32-bit and try test again.
--
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
OK. There have been some comments/questions re: PR18282.
a) my PR is missing that PR, seems we just missed each other.
b) when using my patch I took a suggestion from issue39460 to test again:
root@x065:[/home/python/python3-3.9]./python -m test -v
Change by Michael Felt :
--
pull_requests: +17660
pull_request: https://github.com/python/cpython/pull/18285
___
Python tracker
<https://bugs.python.org/issue39
Michael Felt added the comment:
Seems to be working on 64-bit, starting 32-bit test (with overflow expected).
Once finished will post a PR.
root@x065:[/data/prj/python/python3-3.9]./python
Python 3.9.0a3+ (heads/bpo-39502-dirty:8d49f7ceb4, Jan 30 2020, 14:47:52) [C]
on aix
Type "
Michael Felt added the comment:
>From memory I recall the 64-bit version worked with values above the threshold
>value that broke the 32-bit library.
And the additional test was needed because the AIX library (iirc did not return
NULL on error) - so had to test range before the call
Michael Felt added the comment:
Probably this broke the 64-bit usage.
diff --git a/Python/pytime.c b/Python/pytime.c
index 54ddfc952b..6f13e62490 100644
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -1059,7 +1059,7 @@ _PyTime_localtime(time_t t, struct tm *tm)
return 0;
#else
Change by Michael Felt :
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39502>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
I am looking at this, as/when I can. Was hoping for a ancient school option to
have the compiler stop with assembly code generation ipv objdump. However, I
have not been successful there.
Found objdump, and I'll work from that - and also do some of the tests
New submission from Michael Felt :
Per message: https://bugs.python.org/issue39396#msg360362
opening new issue. Research (as requested) to follow.
--
components: Tests
messages: 360389
nosy: Michael.Felt, vstinner
priority: normal
severity: normal
status: open
title: AIX: FAIL
Michael Felt added the comment:
FYI: On AIX 5.3, after your proposal I get:
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most
Michael Felt added the comment:
A hard call to make, imho.
Thinking aloud...
Currently, for AIX 6.1 and AIX 7.1 your proposal for the code change would be
great, but less so for AIX 7.2.
However! Since libm (on AIX) is a static library - the behavior depends on the
support libm has
Michael Felt added the comment:
As I said, was investigating.
a) is a bug in most AIX system libraries.
b) there is a fix, but not one I can install - as my bots and build systems run
on AIX 6.1 and AIX 7.1
c) the fix is APAR IV95512 which includes fixes in the following filesets:
IV95512
New submission from Michael Felt :
As issue39288 (that introduces this breakage) is closed, opening a new issue.
Back from away - and only starting my investigation - and that will probably be
slow. Have not done anything with IEEE754 in over 30 years.
--
messages: 360312
nosy
Michael Felt added the comment:
quote: Interesting, a comment in curses.h:
* Notes:
* a. ESCDELAY was an undocumented feature under AIX curses.
* It gives the ESC expire time in milliseconds.
iirc - that is a symbolic link to ncurses.h from ncurses-devel RPM package
Michael Felt added the comment:
I am thinking along two lines:
a) tell setup.py to not build _curses, just as _curses_panel
b) figure out how to use configure tests, to establish that ESCDELAY is not
available AND then tell _cursesmodule.* that these routines are not available
(and add
Change by Michael Felt :
--
components: +Extension Modules
___
Python tracker
<https://bugs.python.org/issue39020>
___
___
Python-bugs-list mailing list
Unsub
New submission from Michael Felt :
Did not notice this earlier - as the buildbot does not report it: issue38312
introduced a regression with regard to AIX.
Not sure how to classify component (as Build, C API, or Library, so left blank)
Failed to build these modules:
_curses
Michael Felt added the comment:
Well, I certainly had not considered people would be using
distutils.get_platform().startswith('aix') as I have, in my limited
reading, only seen sys.platform.startswith("aix"). Likewise, do not want
to break things.
I thought this was easier to gra
Michael Felt added the comment:
Updated this PR, and PRs in pypa/pip and pypa/packaging to all be "in sync".
--
___
Python tracker
<https://bugs.python.o
Change by Michael Felt :
--
title: pep425 tag for AIX is inadequate -> Modify AIX platform_tag so it
provides PEP425 needs
___
Python tracker
<https://bugs.python.org/issu
Michael Felt added the comment:
On 26/11/2019 20:10, Paul Moore wrote:
> Paul Moore added the comment:
>
>> replacement platform_tag, not compatibility tag.
> Ah, I see, sorry. In that case, this should be fine, it's purely a CPython
> question. There's obviously a follow-o
Michael Felt added the comment:
On 22/11/2019 10:42, Paul Moore wrote:
> Paul Moore added the comment:
>
> PyPA member here - if this PR is defining new compatibility tags,
replacement platform_tag, not compatibility tag.
> I would have expected it to need discussion as a revisio
101 - 200 of 756 matches
Mail list logo
