[issue40170] [C API] Prepare PyTypeObject structure for a stable ABI: avoid accessing members in the public API
Change by Michael Felt : -- nosy: -Michael.Felt ___ Python tracker <https://bugs.python.org/issue40170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35828] test_multiprocessing_fork: segmentation error in PyDict_GetItem on AIX
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/issue35828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
Change by Michael Felt : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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
# addstr()/insstr()
for func in [stdscr.addstr, stdscr.insstr]:
with self.subTest(func.__qualname__):
stdscr.move(0, 0)
func('abcd')
func(b'abcd')
s = 'à▒^▒ç▒^▒'
try:
func(s)
except UnicodeEncodeError:
self.assertRaises(UnicodeEncodeError, s.encode, encoding)
func('abcd', curses.A_BOLD)
# func(1, 2, 'abcd')
# func(2, 3, 'abcd', curses.A_BOLD)
--
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
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 > status: open -> closed > type: -> compile error > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- Added file: https://bugs.python.org/file49986/OpenPGP_0x722BFDB61F396FC2.asc ___ Python tracker <https://bugs.python.org/issue40878> ___ OpenPGP_0x722BFDB61F396FC2.asc Description: application/pgp-keys ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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/data converged on segment 14 (ie, addresses would begin with 0xe). So, perhaps it is the 0xd* address that is killing everything. See: https://bugs.python.org/issue43665#msg389923 -- as I am also still confused re: this line - looks suspect: with all arguments at 0x PyVectorcall_Call(callable = 0x, tuple = 0x, kwargs = 0x), line 255 in "call.c" And also this line, and lines like it - notice the value for what looks like a variable for argument_count: _PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 0x22023cf0), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 570572016, kwnames = 0x220239f0), line 361 in "call.c" method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames = 0x20045994), line 119 in "abstract.h" -- ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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
status = _PyRuntimeState_ReInitThreads(runtime);
Yet in Posix/ceval.c
PyStatus
_PyEval_ReInitThreads(PyThreadState *tstate)
{
_PyRuntimeState *runtime = tstate->interp->runtime;
** this looks like runtime->interp->runtime
And then we get down to:
/* Destroy all threads except the current one */
_PyThreadState_DeleteExcept(runtime, tstate);
Is this correct - as it looks like:
_PyThreadState_DeleteExcept(runtime->interp->runtime, runtime) -- where runtime
== &_PyRuntime;
--
___
Python tracker
<https://bugs.python.org/issue40092>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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. After calling fork, the child process has exactly 1 thread: all other threads have been removed. * Modify release_sentinel() to not use the lock: avoid PyThread_release_lock() call. ** as to option 1 - it is 'worth it' if it stops the crashes ** This is deeper than I usually go in Python code - but I'll make an effort - help is appreciated. -- ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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 into error. As this seem to be a long-standing issue is it perhaps a possibility to change the test so that the bot can go green again? -- nosy: +Michael.Felt versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
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 script. You can run the script directly: > > ./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $? Status is zero -0 but I get a core dump! aixtools@cpython2:[/home/aixtools/py3a-10.0]./python -X dev Lib/test/test_importlib/partial/pool_in_threads.py ; echo $? 0 aixtools@cpython2:[/home/aixtools/py3a-10.0]ls -ltr core -rw-r--r-- 1 aixtools staff 129435720 Mar 31 16:58 core +++ Looking at the core dump - part 1. +++ The address (0xd118ff80) hints at a shared library (pthread?) I'll try to find it - but maybe you can just remind me - the CLI arguments to make Python more verbose about what it is doing. Note: all addresses beginning with 0x1 (as in 0x101ca238) are program code addresses. 0x3 (0x30163ad8) imply a shared memory segment being created and used by the application. Perhaps more relevant aree all these lines with what appear to be extreme argcount values, e.g., from the bottom: _PyEval_Vector(tstate = 0x30187038, con = 0x20107b40, locals = 0x30111768, args = 0x301219b8, argcount = 806560272, kwnames = 0x301314d8), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = (nil), stack = (nil), nargsf = 570570720, kwnames = (nil)), line 361 in "call.c" _PyEval_EvalFrameDefault(tstate = (nil), f = 0x4000, throwflag = -257396708), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x22023cf0, con = 0x2000120c, locals = 0x22023960, args = 0x220239f0, argcount = 3508213100, kwnames = 0x22023cf0), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x220239f0, stack = (nil), nargsf = 570572016, kwnames = 0x220239f0), line 361 in "call.c" method_vectorcall(method = 0x10103bdc, args = (nil), nargsf = 0, kwnames = 0x20045994), line 119 in "abstract.h" PyVectorcall_Call(callable = 0x, tuple = 0x, kwargs = 0x), line 255 in "call.c" _PyObject_Call(tstate = (nil), callable = (nil), args = (nil), kwargs = (nil)), line 298 in "call.c" thread_run(boot_raw = (nil)), line 1076 in "_threadmodule.c" pythread_wrapper(arg = (nil)), line 240 in "thread_pthread.h" +++ Looking at the core dump - the complete 'where' results: +++ aixtools@cpython2:[/home/aixtools/py3a-10.0]dbx ./python core Type 'help' for help. [using memory image in core] reading symbolic information ... Trace/BPT trap in _internal_error at 0xd118ff80 ($t1) 0xd118ff80 (_internal_error+0x80) 80410014 lwz r2,0x14(r1) (dbx) where _internal_error(??, ??, ??) at 0xd118ff80 pth_usched._usched_dispatch_front._event_notify_locked@AF34_24(??, ??, ??, ??, ??) at 0xd119fc2c _event_notify(??, ??, ??) at 0xd119ee38 _cond_broadcast(??, ??, ??) at 0xd11af588 pthread_cond_signal@AF29_12(??, ??) at 0xd11b1568 pthread_cond_signal(??) at 0xd11afc88 PyThread_release_lock(lock = 0x10119354), line 692 in "thread_pthread.h" release_sentinel(wr_raw = 0x10118f14), line 1289 in "_threadmodule.c" PyThreadState_Clear(tstate = 0x101ca238), line 873 in "pystate.c" _PyThreadState_DeleteExcept(runtime = 0xd5c234d0, tstate = 0x22021d30), line 987 in "pystate.c" _PyEval_ReInitThreads(tstate = 0x30163ad8), line 506 in "ceval.c" PyOS_AfterFork_Child(), line 600 in "posixmodule.c" os_fork_impl(module = 0x3033a030), line 6659 in "posixmodule.c" cfunction_vectorcall_NOARGS(func = 0x30337330, args = 0x302ec7d0, nargsf = 570564304, kwnames = 0x30337328), line 485 in "methodobject.c" _PyEval_EvalFrameDefault(tstate = 0x302e058c, f = 0x302e847a, throwflag = 0), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x302f2350, con = 0x20107b40, locals = 0x302e8478, args = 0x302e79b8, argcount = 808016112, kwnames = 0x302cd898), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x0008, stack = 0x3004d6e8, nargsf = 570564752, kwnames = 0x302f6030), line 361 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x101c9554, f = 0x20107b40, throwflag = 570565024), line 1431 in "abstract.h" _PyEval_Vector(tstate = 0x0018, con = 0x200084a0, locals = 0x220221f0, args = 0x88000284, argcount = 269576140, kwnames = 0x2007a390), line 46 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x2007a4e0, stack = 0x20107b40, nargsf = 570565168, kwnames = 0x20045994), line 361 in "call.c" _PyObject_FastCallDictTstate(tstate = 0x100a7e84, callable = 0x302ed780, args = 0x220222b0, nargsf = 537155988, kwargs = 0x100a8a54), line 142 in "call.c" _PyObject_Call_Prepen
[issue28276] test_loading.py - false positive result for "def test_find" when find_library() is not functional or the (shared) library does not exist
Michael Felt added the comment: Sure. Probably have to rebase first. -- ___ Python tracker <https://bugs.python.org/issue28276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
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: > > ./python -m test.bisect_cmd -o bisect --fail-env-changed test_importlib > > The command should takes 10-60 minutes, and you should see the number of > tests decreasing. I hope that at the end, the command will identify a single > method triggering the crash. > > At the end, the create "bisect" file contains the test methods causing the > bug. > > Then you can re-run tests with: > > ./python -m test --fail-env-changed test_importlib --matchfile=bisect I like this!: Fortunately, it did not take 10 minutes: Writing 1 tests into bisect Tests (1): * test.test_importlib.test_threaded_import.ThreadedImportTests.test_multiprocessing_pool_circular_import Output written into bisect Bisection completed in 34 iterations and 0:00:28 > > >> 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 is actually having issues. > You can re-run the test without libregrtest by running it directly. Example: > > ./python -m test.test_importlib > test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v While - to use your example - using the normal verbose test syntax I do see the test you reference: * test_reload (test.test_importlib.test_spec.Frozen_ModuleSpecMethodsTests) ... ok but, when I run your example (and many variations) I always get something such as: So, still - closer - but not quite there with: + ./python -m test.test_importlib test_spec.Frozen_ModuleSpecMethodsTests.test_reload -v test_spec (unittest.loader._FailedTest) ... ERROR == ERROR: test_spec (unittest.loader._FailedTest) -- AttributeError: module '__main__' has no attribute 'test_spec' -- Ran 1 test in 0.000s FAILED (errors=1) + > It should create a core dump in the current directory, or you run the command > in your favorite debugger. > > > My notes on debugging a Python crash: > https://pythondev.readthedocs.io/debug_tools.html#core-dump > > -- > nosy: +vstinner > > ___ > Python tracker > <https://bugs.python.org/issue43665> > ___ > -- Added file: https://bugs.python.org/file49922/OpenPGP_0x722BFDB61F396FC2.asc ___ Python tracker <https://bugs.python.org/issue43665> ___ OpenPGP_0x722BFDB61F396FC2.asc Description: application/pgp-keys ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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 = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c" IPRA.$_curses_window_insstr_impl(self = 0x100fd954, group_left_1 = -739652824, y = 804382672, x = 804382676, str = 0x2ff1e7dc, group_right_1 = -739620304, attr = 0), line 1855 in "_cursesmodule.c" _curses_window_insstr(self = 0x100a96ec, args = 0x20088288), line 1160 in "_cursesmodule.c.h" cfunction_call(func = 0x305337d0, args = 0x20088288, kwargs = 0x2ff1e8b0), line 567 in "methodobject.c" _PyObject_MakeTpCall(tstate = (nil), callable = 0x20088288, args = 0x2ff1e930, nargs = 131, keywords = 0x10167b48), line 215 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x100b2a6c, f = 0x303a1268, throwflag = 806335952), line 1429 in "abstract.h" _PyEval_Vector(tstate = 0x100ef278, con = 0x300fd59a, locals = 0x2ff1ea90, args = 0x20045994, argcount = 806339296, kwnames = 0x300ff6a0), line 46 in "pycore_ceval.h" -- ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
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/issue43666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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/test.out ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43666] AIX: Lib/_aix_support.py may break in a WPAR environment
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) situations - so that, in any case, the build of Python can proceed. -- components: Library (Lib) messages: 389804 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: Lib/_aix_support.py may break in a WPAR environment versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43665] AIX: test_importlib regression (ENV change)
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 is actually having issues. e.g., see https://buildbot.python.org/all/#/builders/438/builds/1031/steps/5/logs/stdio for current bot exit status Thx for assistance. -- components: Tests messages: 389797 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: test_importlib regression (ENV change) versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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 sane ^J
needed).
--
Added file: https://bugs.python.org/file49917/issue43659.zip
___
Python tracker
<https://bugs.python.org/issue43659>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43659] AIX: test_curses crashes buildbot
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 libcurses.a does not include support for update_lines_cols(). This patch should allow test_curses.py to pass in the buildbot. When run from command-line as: $ TERM=unknown ./python Lib/test/test_curses.py .ss..ss -- Ran 71 tests in 0.121s OK (skipped=64) aixtools@cpython2:[/home/aixtools/py3a-10.0] (When TERM is defined - a core dump still occurs - that will be a new issue and a new PR). -- components: Tests messages: 389716 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: test_curses crashes buildbot versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault using xlc-v11
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, it is 'starting' in this area: _PyPegen_run_parser(p = 0x0fffcb40), line 1121 in "pegen.c" _PyPegen_run_parser_from_string(str = "compile", start_rule = 1, filename_ob = 0x0001100ee2b0, flags = 0x0707fb30, arena = 0x070d3330), line 1250 in "pegen.c" PyPegen_ASTFromStringObject(str = warning: Unable to access address 0x15d4 from core (invalid char ptr (0x15d4)), filename = (nil), mode = 268435455, flags = 0x482448c2, arena = 0x0001001a1e3c), line 27 in "peg_api.c" Py_CompileStringObject(str = "", filename = (nil), start = 268435455, flags = 0x0707fb30, optimize = 268435455), line 1274 in "pythonrun.c" builtin_compile_impl(module = 0x000100077a0c, source = (nil), filename = 0x00011e28, mode = "", flags = 1, dont_inherit = 1, optimize = 0, feature_version = 0), line 819 in "bltinmodule.c" builtin_compile(module = (nil), args = 0x0001100741c0, nargs = 2, kwnames = 0x070068f0), line 274 in "bltinmodule.c.h" cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x0fffd030, args = 0x1300, nargsf = 0, kwnames = 0x0008), line 457 in "methodobject.c" Here is the complete 'where' status: (dbx) where strncmp.strncmp(??, ??, ??) at 0x901b3a0 _get_keyword_or_name_type(p = 0x0020, name = (nil), name_len = 0), line 535 in "pegen.c" _PyPegen_fill_token(p = 0x0001001be088), line 638 in "pegen.c" _PyPegen_is_memoized(p = 0x0020, type = 0, pres = 0x0fffc370), line 716 in "pegen.c" dotted_name_rule(p = 0x0fffc400), line 3443 in "parse.c" dotted_as_name_rule@AF452_298(??), line 3410 in "parse.c" _gather_36_rule@AF453_127(??), line 17755 in "parse.c" dotted_as_names_rule@AF454_299(??), line 3368 in "parse.c" import_name_rule(p = 0x0fffc660), line 3000 in "parse.c" import_stmt_rule@AF462_305(??), line 2932 in "parse.c" small_stmt_rule(p = 0x0fffc7a0), line 1606 in "parse.c" unnamed block in simple_stmt_rule(p = 0x0001000df758), line 1428 in "parse.c" simple_stmt_rule(p = 0x0001000df758), line 1428 in "parse.c" unnamed block in statement_rule(p = 0x15d5), line 1262 in "parse.c" statement_rule(p = 0x15d5), line 1262 in "parse.c" _loop1_11_rule(p = 0x0001000df6d4), line 16254 in "parse.c" statements_rule@AF475_318(??), line 1197 in "parse.c" file_rule@AF476_324(??), line 730 in "parse.c" _PyPegen_run_parser(p = 0x0fffcb40), line 1121 in "pegen.c" _PyPegen_run_parser_from_string(str = "compile", start_rule = 1, filename_ob = 0x0001100ee2b0, flags = 0x0707fb30, arena = 0x070d3330), line 1250 in "pegen.c" PyPegen_ASTFromStringObject(str = warning: Unable to access address 0x15d4 from core (invalid char ptr (0x15d4)), filename = (nil), mode = 268435455, flags = 0x482448c2, arena = 0x0001001a1e3c), line 27 in "peg_api.c" Py_CompileStringObject(str = "", filename = (nil), start = 268435455, flags = 0x0707fb30, optimize = 268435455), line 1274 in "pythonrun.c" builtin_compile_impl(module = 0x000100077a0c, source = (nil), filename = 0x00011e28, mode = "", flags = 1, dont_inherit = 1, optimize = 0, feature_version = 0), line 819 in "bltinmodule.c" builtin_compile(module = (nil), args = 0x0001100741c0, nargs = 2, kwnames = 0x070068f0), line 274 in "bltinmodule.c.h" cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x0fffd030, args = 0x1300, nargsf = 0, kwnames = 0x0008), line 457 in "methodobject.c" PyVectorcall_Call(callable = 0x0fffd0c0, tuple = 0x070b9900, kwargs = 0x070bf1c8), line 257 in "call.c" do_call_core(tstate = 0x0001, func = 0x0002, callargs = 0x0001, kwdict = 0x0001100741c0), line 5092 in "ceval.c" _PyEval_EvalFrameDefault(tstate = 0x0fffd370, f = 0x070aced8, throwflag = 1), line 3580 in "ceval.c" _PyEval_EvalCode(tstate = 0x9f63fdf1699118db, _co = 0x0704ed80, globals = 0x070754c0, locals = 0x07051070, args = 0x0fffd4a0, argcount = 4765972565237396600, kwnames = 0x0001000bb5e4, kwargs = 0x070683b0, kwcount = 2, kwstep = 0, defs = (nil), defcount = 0, kwdefs = (nil), closure = (
[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX
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 - IV95112 (and more) do not seem to return NaN when one of the arguments is NaN. -- ___ Python tracker <https://bugs.python.org/issue42323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX
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) a (major?) change was made to the nextafter() function. root@gcc119:[/home2/root]instfix -k IV95512 -a IV95512 Abstract: nextafter(+0.0, -0.0) returns +0.0 instead of -0.0. IV95512 Symptom Text: If(x==y) nextafter returns x instead of y. At first glance - it appears the CPython code is reversing the arguments: The lines in test_math.py are currently: +2026 # NaN +2027 self.assertIsNaN(math.nextafter(NAN, 1.0)) +2028 self.assertIsNaN(math.nextafter(1.0, NAN)) +2029 self.assertIsNaN(math.nextafter(NAN, NAN)) Moving line 2027 (which is what is failing) to 2029 - the other two lines pass on an AIX system with IV95512 applied. As IEEE754 says (and seems to have always said): https://pubs.opengroup.org/onlinepubs/9699919799: If x or y is NaN, a NaN shall be returned. The current test in Modules/mathmodule.c might be too simple. I am working on a PR where I check for presence of APAR IV95512 - with the nextafter() changes. -- ___ Python tracker <https://bugs.python.org/issue42323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42701] Discrepency between configure.ac and configure
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 for. -- resolution: -> third party ___ Python tracker <https://bugs.python.org/issue42701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42701] Discrepency between configure.ac and configure
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 in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 3936.
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Tom Tromey
and Alexandre Duret-Lutz .
Will test on a system where I can install the latest automake.
Assuming an updated version of automake fixes that - but not knowing autotools
well enough - is there a simple addition to ensure that automake-1.16 is used?
--
___
Python tracker
<https://bugs.python.org/issue42701>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42701] Discrepency between configure.ac and configure
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 Viktorin Date: Thu Oct 22 18:11:53 2020 +0200 bpo-38980: Only apply -fno-semantic-interposition if available (GH-22892) :100644 100644 b5f9cb0e8da44fb378e7e082f23025901cb06c6c 99913e7f3b85cf9ebba261073883c50b3f9a9ecd M aclocal.m4 :100755 100755 df7118f68d3bb484148f8b719b1550676c029493 29f33b543ecc02c8eaae7cfd66c442a4bd60d44a M configure :100644 100644 c63c1e88a2302f7a60e9c2319f9965c1d7830d47 9698c3c888a6b7f74f2458df94bf21e51b6793d7 M configure.ac -- ___ Python tracker <https://bugs.python.org/issue42701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42701] Discrepency between configure.ac and configure
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 (HEAD -> master, upstream/master, upstream/HEAD, bpo-42323) [WIP/RFC]
bpo-15872: tests: remove oddity from test_rmtree_errors (GH-22967)
ab74c01 bpo-31904: Fix site and sysconfig modules for VxWorks RTOS (GH-21821)
c95f8bc bpo-42669: Document that `except` rejects nested tuples (GH-23822)
b0398a4 bpo-42572: Improve argparse docs for the type parameter. (GH-23849)
a44ce6c bpo-42604: always set EXT_SUFFIX=${SOABI}${SHLIB_SUFFIX} when using
configure (GH-23708)
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]rpm -qa autoconf
autoconf-2.69-2.noarch
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /opt/freeware/bin/autoconf
autoreconf: running: /opt/freeware/bin/autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'
Your branch is up-to-date with 'upstream/master'.
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: aclocal.m4
modified: configure
modified: pyconfig.h.in
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]git diff configure
diff --git a/configure b/configure
index f07edff..6f0d51f 100755
--- a/configure
+++ b/configure
@@ -6471,44 +6471,10 @@ if test "$Py_OPT" = 'true' ; then
DEF_MAKE_RULE="build_all"
case $CC in
*gcc*)
- { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether C compiler
accepts -fno-semantic-interposition" >&5
-$as_echo_n "checking whether C compiler accepts -fno-semantic-interposition...
" >&6; }
-if ${ax_cv_check_cflags___fno_semantic_interposition+:} false; then :
- $as_echo_n "(cached) " >&6
-else
-
- ax_check_save_flags=$CFLAGS
- CFLAGS="$CFLAGS -fno-semantic-interposition"
- cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h. */
-
-int
-main ()
-{
-
- ;
- return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
- ax_cv_check_cflags___fno_semantic_interposition=yes
-else
- ax_cv_check_cflags___fno_semantic_interposition=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
- CFLAGS=$ax_check_save_flags
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$ax_cv_check_cflags___fno_semantic_interposition" >&5
-$as_echo "$ax_cv_check_cflags___fno_semantic_interposition" >&6; }
-if test "x$ax_cv_check_cflags___fno_semantic_interposition" = xyes; then :
-
+ AX_CHECK_COMPILE_FLAG(-fno-semantic-interposition,
CFLAGS_NODIST="$CFLAGS_NODIST -fno-semantic-interposition"
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]./configure
checking for git... found
checking build system type... powerpc-ibm-aix7.2.4.0
checking host system type... powerpc-ibm-aix7.2.4.0
checking for python3.10... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "aix"
checking for gcc... gcc
checking whether the C compiler works... yes
...
checking for --with-pydebug... no
checking for --with-trace-refs... no
checking for --with-assertions... no
checking for --enable-optimizations... no
./configure[6464]: syntax error at line 6475 : `(' unexpected
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]
Unclear - to me - what is wrong with configure.ac or autoconf that is installed.
aixtools@gcc119:[/home/aixtools/cpython/cpython-master]autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
--
components: Build
messages: 383515
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Discrepency between configure.ac and configure
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42701>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41625] Add splice() to the os module
Michael Felt added the comment: Sorry Victor - family matters - so I was not watching for several days. -- ___ Python tracker <https://bugs.python.org/issue41625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
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 compare.
So, likely the change to the tests would be to have one for NT (per the comment
in Lib/sysconfig.py) and the prior test set to be skipped if the platform is
`NT` aka non_posix.
--
___
Python tracker
<https://bugs.python.org/issue39825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39825] EXT_SUFFIX inconsistent between sysconfig and distutils.sysconfig (Windows)
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 3.6.12 (default, Sep 23 2020, 08:27:01) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var('EXT_SUFFIX')
'.so'
>>> from distutils import sysconfig
>>> sysconfig.get_config_var('EXT_SUFFIX')
'.so'
I am guessing that distutils has not updated - whatever - for AIX, FreeBSD, and
perhaps others.
@mattip: is the problem perhaps with distutils rather than a particular
platform. I also admit, I do not know what 'EXT_SUFFIX' is suppossed to return.
From past behavior I took it to mean a file 'tag' for files that are accessed
using dlopen().
Is it - perhaps - that different platforms have different needs or abilities -
and the error is not the platform - but the adequacy of tests to differentiate
platform behavior. I am guessing now - but maybe that is why distutils has not
changed AIX and FreeBSD and maybe more.
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41625] Add splice() to the os module
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 continues to fail compile at the same location - while the second bot (running in a different environment) starting passing compile and all tests starting with https://buildbot.python.org/all/#/builders/302/builds/406. Note: bot 1 is using what I call (personal opinion) a mixed environment with some libraries coming from OSS packages and some from IBM AIX. bot 2 - relies on IBM AIX libraries. ++ Note: manual build on same system as bot 1 using gcc - gives same error: aixtools@gcc119:[/home/aixtools/cpython/cpython-master]make V=1 gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -O -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include-DPy_BUILD_CORE -DABIFLAGS='""'-o Python/sysmodule.o ./Python/sysmodule.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -O -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include-DPy_BUILD_CORE -o Modules/config.o Modules/config.c gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -O -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include -DPy_BUILD_CORE_BUILTIN -DPy_BUILD_CORE_BUILTIN -I./Include/internal -c ./Modules/posixmodule.c -o Modules/posixmodule.o ./Modules/posixmodule.c: In function 'os_splice_impl': ./Modules/posixmodule.c:10429:15: error: implicit declaration of function 'splice'; did you mean 'plock'? [-Werror=implicit-function-declaration] ret = splice(src, p_offset_src, dst, p_offset_dst, count, flags); ^~ plock cc1: some warnings being treated as errors make: 1254-004 The error code from the last command is 1. * On same system, using xlc-v13, the build completes normally. -- nosy: +Michael.Felt ___ Python tracker <https://bugs.python.org/issue41625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX
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: 1506-045 (S) Undeclared identifier SPLICE_F_MOVE. "./Modules/posixmodule.c", line 15147.57: 1506-045 (S) Undeclared identifier SPLICE_F_NONBLOCK. "./Modules/posixmodule.c", line 15148.53: 1506-045 (S) Undeclared identifier SPLICE_F_MORE. So, let's put this on hold. I'll get a new environment built up specific for testing python on AIX. Hopefully by Friday. -- ___ Python tracker <https://bugs.python.org/issue42323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX
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 (AIX 6.1 TL6) - no error AIX 7.1.4, using xlc-v13.1.2 (try and buy version), same AIX level as the bot (7.1 TL4 SP8) - no error Back to the bot: AIX 7.1 TL4 SP8 and gcc-4.7.4 - strange errors. See, e.g., https://buildbot.python.org/all/#/builders/302/builds/373/steps/5/logs/stdio with additional errors such as: == FAIL: testHypotAccuracy (test.test_math.MathTests) (hx='0x1.89d8c423ea0c6p+29', hy='0x1.d35dcfe902bc3p+29', x=825956484.4892814, y=980138493.1263355) -- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_math.py", line 867, in testHypotAccuracy self.assertEqual(hypot(x, y), z) AssertionError: 1281747081.1271062 != 1281747081.127106 Waiting for bot run 374 - to see if the results change when the compiler changes. I'll try moving the bot to another system - as the system the bot is on is more than just the bot. Maybe there are side-effects coming in, unexpectedly, from other sources. ** The two systems just mentioned are fresh installs. -- ___ Python tracker <https://bugs.python.org/issue42323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault using xlc-v11
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! -- title: BUILD: AIX-64-bit segmentation fault using xlc -> BUILD: AIX-64-bit segmentation fault using xlc-v11 ___ Python tracker <https://bugs.python.org/issue42309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42323] [AIX] test_math: test_nextafter(float('nan'), 1.0) does not return a NaN on AIX
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 the test on POWER6 I get many more errors - that I never had before. These are all after OS updates (I was not going to build for AIX 5.3 any more). An idea I have now - that may explain the sudden change in behavior is if the libraries have been optimized to always use the DFP (decimal floating point) internally - for what, from the application perspective - is the normal - no HW acceleration for FP - interface. I know there are ways to 'discover' this, but I'll need to write some tests so that I can see - if linking to different libraries actuates DFP performance counters yes and no. At this point - this feels like the a potential explanation. -- ___ Python tracker <https://bugs.python.org/issue42323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault using xlc
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 fault using xlc ___ Python tracker <https://bugs.python.org/issue42309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault
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. -- ___ Python tracker <https://bugs.python.org/issue42309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault
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-phase" python executable: ``` ../src/py39-3.9.0/Modules/makexp_aix Modules/python.exp "." libpython3.9.a xlc_r -Wl,-bE:Modules/python.exp -lld -o python Programs/python.o libpython3.9.a -lintl -ldl -lm -lm ./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 /bin/sh: 6291700 Segmentation fault(coredump) make: 1254-004 The error code from the last command is 139. Stop. root@x066:[/data/prj/python/py39-3.9.0]./python -E -S -m sysconfig --generate-posix-vars Segmentation fault(coredump) root@x066:[/data/prj/python/py39-3.9.0]./python Segmentation fault(coredump) ``` Will try to duplicate in a second environment. -- components: Build messages: 380654 nosy: Michael.Felt priority: normal severity: normal status: open title: BUILD: AIX-64-bit segmentation fault type: crash versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41401] Using non-ascii that require UTF-8 breaks AIX testing
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! -- ___ Python tracker <https://bugs.python.org/issue41401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
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 on the better approach. Closing one (asap) is a good idea, especially if that leads to something being merged so this is finally repaired. Sent from my iPhone > On 15 Aug 2020, at 23:07, Stefan Krah wrote: > > > Stefan Krah added the comment: > > I understand that both of you are in favor of #19521 (the patch of > which I have not tried yet). > > Can we close this as a duplicate? Please just reopen if you disagree. > > -- > nosy: +skrah > resolution: -> duplicate > stage: patch review -> resolved > status: open -> closed > superseder: -> Parallel build race condition on AIX since python-2.7 > > ___ > Python tracker > <https://bugs.python.org/issue40424> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41461] test_pathlib assumes underlying filesystem permits creation with world-write permissions
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 possible ways to react to an exception such as this, e.g., rather than 'FAIL' outright, try umask(2). == FAIL: test_open_mode (test.test_pathlib.PosixPathTest) -- Traceback (most recent call last): File "/data/prj/python/src/py38-3.8.5/Lib/test/test_pathlib.py", line 2210, in test_open_mode self.assertEqual(stat.S_IMODE(st.st_mode), 0o666) AssertionError: 436 != 438 == FAIL: test_touch_mode (test.test_pathlib.PosixPathTest) -- Traceback (most recent call last): File "/data/prj/python/src/py38-3.8.5/Lib/test/test_pathlib.py", line 2223, in test_touch_mode self.assertEqual(stat.S_IMODE(st.st_mode), 0o666) AssertionError: 436 != 438 -- Just to verify it does work when on a 'local' filesystem. cp -rp build /tmp/build mv build build.nfs ln -s /tmp/build build == Tests result: SUCCESS == 1 test OK. Total duration: 7.8 sec Tests result: SUCCESS -- components: Tests messages: 374725 nosy: Michael.Felt priority: normal severity: normal status: open title: test_pathlib assumes underlying filesystem permits creation with world-write permissions type: behavior versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41401] Using non-ascii that require UTF-8 breaks AIX testing
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/issue41401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41401] Using non-ascii that require UTF-8 breaks AIX testing
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), pack-reused 8 Unpacking objects: 100% (58/58), done. >From https://github.com/python/cpython * [new ref] refs/pull/21640/head -> pr_21640 aixtools@gcc119:[/home/aixtools/cpython/cpython-master]./python -m test test_io 0:00:00 Run tests sequentially 0:00:00 [1/1] test_io test_io passed in 1 min == Tests result: SUCCESS == 1 test OK. Total duration: 1 min Tests result: SUCCESS On 27/07/2020 16:16, Serhiy Storchaka wrote: > Change by Serhiy Storchaka : > > > -- > keywords: +patch > pull_requests: +20781 > stage: -> patch review > pull_request: https://github.com/python/cpython/pull/21640 > > ___ > Python tracker > <https://bugs.python.org/issue41401> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
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/issue18280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
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 of a sentence. On 26/07/2020 18:39, Serhiy Storchaka wrote: > Serhiy Storchaka added the comment: > > I think they are not required, but recommended. > > >From https://www.python.org/dev/peps/pep-0008/#comments: > >You should use two spaces after a sentence-ending period in multi- > sentence comments, except after the final sentence. > > >From https://www.python.org/dev/peps/pep-0012/#general: > >You must adhere to the Emacs convention of adding two spaces at the end of > every sentence. > > AFAIK in English typography the space after a sentence-ending period is > longer than spaces between words. In other European typographies they have > the same width. I thought it was where type setters, classically, used the break between the endings of a sentence - additional 'kerning' could be applied there. Anyway - final question: does .rst reformat line-lingths, or does it present everything literally - only adding ``embellishments``. I have been thinking it does both - and, yet another convention for sentence endings is to always start a sentence on a new line (and two new-lines indicate start of a paragraph. However, for now - double-spaces will remain - and I hope to remember to add my own :) > -- > > ___ > Python tracker > <https://bugs.python.org/issue18280> > ___ > -- ___ Python tracker <https://bugs.python.org/issue18280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41401] Using non-ascii that require UTF-8 breaks AIX testing
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▒ == CPU count: 32 == encodings: locale=ISO8859-1, FS=iso8859-1 0:00:00 Run tests sequentially 0:00:00 [1/1] test_io test_fspath_support (test.test_io.CIOTest) ... ok -- Ran 1 test in 0.026s OK Warning -- files was modified by test_io Before: [] After: ['@test_27984450_tmpæ'] test_io failed (env changed) + == 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_28246552▒ == CPU count: 32 == encodings: locale=ISO8859-1, FS=iso8859-1 0:00:00 Run tests sequentially 0:00:00 [1/1] test_io test_fspath_support (test.test_io.PyIOTest) ... ok -- Ran 1 test in 0.026s OK Warning -- files was modified by test_io Before: [] After: ['@test_28246552_tmpæ'] test_io failed (env changed) == Tests result: SUCCESS == 1 test altered the execution environment: test_io == 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_33620404▒ == CPU count: 32 == encodings: locale=ISO8859-1, FS=iso8859-1 0:00:00 Run tests sequentially 0:00:00 [1/1] test_io test_reader_writer_close_error_on_close (test.test_io.CBufferedRWPairTest) ... ok -- Ran 1 test in 0.001s OK Warning -- Unraisable exception Exception ignored in: <_io.BufferedRWPair object at 0x30689750> Traceback (most recent call last): File "/home/aixtools/cpython/cpython-master/Lib/test/support/__init__.py", line 613, in gc_collect gc.collect() ValueError: flush of closed file Warning -- Unraisable exception Exception ignored in: <_io.BufferedWriter> Traceback (most recent call last): File "/home/aixtools/cpython/cpython-master/Lib/test/support/__init__.py", line 613, in gc_collect gc.collect() ValueError: flush of closed file test_io failed (env changed) == Tests result: SUCCESS == 1 test altered the execution environment: test_io Hope this helps! -- ___ Python tracker <https://bugs.python.org/issue41401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
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., is
replacing them with a single ' ', or otherwise, a new line ('\n') an error.
iirc - new paragraphs are indicated by two new-lines.
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue18280>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41401] Using non-ascii that require UTF-8 breaks AIX testing
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 Date: Thu Jun 25 17:56:31 2020 +0300 bpo-41069: Make TESTFN and the CWD for tests containing non-ascii characters. (GH-21035) commit f925407a19eeb9bf5f7640143979638adce2c677 Author: Serhiy Storchaka Date: Thu Jun 25 20:39:12 2020 +0300 [3.9] bpo-41069: Make TESTFN and the CWD for tests containing non-ascii characters. (GH-21035). (GH-21156) (cherry picked from commit 700cfa8c90a90016638bac13c4efd03786b2b2a0) Sadly, I cannot determine - exactly - where it is going wrong as the verbose results ends (says SUCCESS, but there is an ENV change, so bot says FAILED) as: -- Ran 614 tests in 59.122s OK (skipped=8) Warning -- files was modified by test_io Before: [] After: ['@test_23134518_tmpæ'] test_io failed (env changed) in 59.7 sec == Tests result: SUCCESS == 1 test altered the execution environment: test_io Total duration: 59.8 sec -- components: IO, Tests messages: 374312 nosy: Michael.Felt priority: normal severity: normal status: open title: Using non-ascii that require UTF-8 breaks AIX testing type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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_EvalFrameDefault at line 941 in file "../git/py39-3.10/Include/object.h" ($t1) "object.h" has only 659 lines (dbx) where _PyEval_EvalFrameDefault(tstate = 0x3009c9d0, f = 0x0017, throwflag = 15), line 941 in "object.h" _PyEval_EvalCode(tstate = 0x1001c454, _co = 0x3009c250, globals = 0x2ff20260, locals = 0x10324233, args = 0x100b2798, argcount = 44, kwnames = 0x2ff20280, kwargs = 0x2228228f, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalCodeWithName(_co = 0x0003, globals = 0x2ff20340, locals = 0x2ff202f0, args = 0x2004429c, argcount = 805945904, kwnames = (nil), kwargs = 0x2ff202f0, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4416 in "ceval.c" PyEval_EvalCodeEx(_co = 0x10110c74, globals = 0x200817a2, locals = (nil), args = 0x30091598, argcount = 805901716, kws = 0x200817da, kwcount = 537401128, defs = 0x30078f58, defcount = 0, kwdefs = (nil), closure = (nil)), line 4415 in "ceval.c" builtin___build_class__(self = 0x100b8bdc, args = (nil), nargs = 804389872, kwnames = 0x2004429c), line 222 in "bltinmodule.c" cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100d5e54, args = (nil), nargsf = 805553488, kwnames = 0x3004658c), line 459 in "methodobject.c" _PyEval_EvalFrameDefault(tstate = 0x300912d8, f = 0x30050c8c, throwflag = 805485032), line 628 in "abstract.h" _PyEval_EvalCode(tstate = 0x10110c74, _co = 0x3004abb8, globals = 0x30095fa8, locals = 0x3009d16c, args = 0x3009d168, argcount = 805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x30092258, locals = 0x2ff20680, args = 0x2004429c, argcount = 269191840, kwnames = 0x300550e0, kwargs = 0x2ff20680, kwcount = 1109926476, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4416 in "ceval.c" PyEval_EvalCodeEx(_co = 0x10090ab0, globals = (nil), locals = 0xf0653ea8, args = 0xf0653ea8, argcount = 0, kws = 0x20082720, kwcount = 804390704, defs = 0x2228228f, defcount = 0, kwdefs = (nil), closure = (nil)), line 4415 in "ceval.c" PyEval_EvalCode(co = 0x103a1274, globals = 0x103a155e, locals = 0x30099978), line 857 in "ceval.c" builtin_exec_impl(module = 0x300912c4, source = 0x30050cb8, globals = 0x20060a78, locals = 0x0002), line 1035 in "bltinmodule.c" builtin_exec(module = 0x100d58b4, args = 0x30050cb8, nargs = 0), line 371 in "bltinmodule.c.h" cfunction_vectorcall_FASTCALL(func = 0x, args = 0x30050b80, nargsf = 804391008, kwnames = 0x2004429c), line 443 in "methodobject.c" PyVectorcall_Call(callable = 0x1001e5cc, tuple = 0x20060a78, kwargs = 0x2ff208c0), line 249 in "call.c" _PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args = 0x2ff20920, kwargs = 0x2004429c), line 265 in "call.c" do_call_core(tstate = 0x0002, func = 0x20026bc0, callargs = 0x2ff20990, kwdict = 0x3004abb8), line 5142 in "ceval.c" _PyEval_EvalFrameDefault(tstate = 0x, f = 0x3004a070, throwflag = 804391536), line 3603 in "ceval.c" _PyEval_EvalCode(tstate = 0x3005e9b0, _co = 0x30062290, globals = (nil), locals = 0x20026020, args = 0x300922f8, argcount = 805331176, kwnames = 0x2ff20b30, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8, qualname = 0x300197c8), line 40 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x3005dbac, stack = (nil), nargsf = 805553488, kwnames = 0x30040960), line 417 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x300921b8, throwflag = 804392064), line 628 in "abstract.h" function_code_fastcall(tstate = 0x30087538, co = 0x3004a1b0, args = 0x2000af70, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = (nil), f = 0x0001, throwflag = 804392400), line 628 in "abstract.h" function_code_fastcall(tstate = 0x30042fcc, co = 0x30031176, args = 0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060a78, throwflag = 804392736), line 628 in "abstract.h" function_code_fastcall(tstate = 0x00e0, co = 0x009c, args = 0x300
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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, master does not. Will provide more info on master later. > 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: >> Pablo Galindo Salgado added the comment: >> >> Michael, could you check the latest master and 3.9 HEAD? If you don;t see >> the problem anymore, we can close this issue :) >> >> -- >> >> ___ >> Python tracker >> <https://bugs.python.org/issue41215> >> ___ >> > -- > > ___ > Python tracker > <https://bugs.python.org/issue41215> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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: > Pablo Galindo Salgado added the comment: > > Michael, could you check the latest master and 3.9 HEAD? If you don;t see the > problem anymore, we can close this issue :) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41215> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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-islington added the comment: > > > New changeset 1ac0cbca369f16f9191833dd54536482fb141a98 by Pablo Galindo in > branch 'master': > bpo-41215: Don't use NULL by default in the PEG parser keyword list (GH-21355) > https://github.com/python/cpython/commit/1ac0cbca369f16f9191833dd54536482fb141a98 > > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41215> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 "../git/py39-3.10/Include/object.h" ($t1) "object.h" has only 659 lines (dbx) where _PyEval_EvalFrameDefault(tstate = 0x300af594, f = 0x0017, throwflag = 15), line 941 in "object.h" _PyEval_EvalCode(tstate = 0x1001c454, _co = 0x30092520, globals = 0x2ff20190, locals = 0x10324213, args = 0x100b2798, argcount = 44, kwnames = 0x2ff201b0, kwargs = 0x2228228f, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalCodeWithName(_co = 0x0003, globals = 0x2ff20270, locals = 0x2ff20220, args = 0x2004426c, argcount = 806222336, kwnames = (nil), kwargs = 0x2ff20220, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4416 in "ceval.c" PyEval_EvalCodeEx(_co = 0x10110c74, globals = 0x20095072, locals = (nil), args = 0x300af598, argcount = 806024596, kws = 0x200950aa, kwcount = 537481208, defs = 0x300bcf10, defcount = 0, kwdefs = (nil), closure = (nil)), line 4415 in "ceval.c" builtin___build_class__(self = 0x100b8bdc, args = (nil), nargs = 804389664, kwnames = 0x2004426c), line 222 in "bltinmodule.c" cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x20060d88, args = 0x30046448, nargsf = 805553488, kwnames = 0x3004abb8), line 459 in "methodobject.c" _PyEval_EvalFrameDefault(tstate = 0x01ff, f = 0x200012d0, throwflag = 80439), line 628 in "abstract.h" _PyEval_EvalCode(tstate = 0x100d4eb4, _co = 0x3003f440, globals = 0x300b2ca8, locals = 0x300b516c, args = 0x300b5168, argcount = 805586012, kwnames = 0x30044450, kwargs = 0x30001028, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalCodeWithName(_co = 0x3004abd8, globals = 0x300ac910, locals = 0x2ff205b0, args = 0x2004426c, argcount = 269191840, kwnames = 0x2ff2060c, kwargs = 0x, kwcount = 0, kwstep = 2, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = (nil), qualname = (nil)), line 4416 in "ceval.c" PyEval_EvalCodeEx(_co = 0x10090ab0, globals = 0x0004, locals = 0x30062be8, args = (nil), argcount = 805624984, kws = 0x20060d88, kwcount = 804390432, defs = 0x0004, defcount = 0, kwdefs = (nil), closure = (nil)), line 4415 in "ceval.c" PyEval_EvalCode(co = 0x103a1254, globals = 0x103a153e, locals = 0x300d1a48), line 857 in "ceval.c" builtin_exec_impl(module = 0x300b8ec8, source = 0x300671d8, globals = 0x2002af08, locals = 0x300af170), line 1035 in "bltinmodule.c" builtin_exec(module = 0x30059f6c, args = 0x30050d20, nargs = 804390720), line 371 in "bltinmodule.c.h" cfunction_vectorcall_FASTCALL(func = 0x101c1120, args = 0x3006906c, nargsf = 805736544, kwnames = 0x2004426c), line 443 in "methodobject.c" PyVectorcall_Call(callable = 0xd0129a34, tuple = 0x3008c028, kwargs = 0x2ff207f0), line 249 in "call.c" _PyObject_Call(tstate = 0x100b259c, callable = 0x30027ce2, args = 0x2ff20850, kwargs = 0x000c), line 265 in "call.c" do_call_core(tstate = (nil), func = (nil), callargs = 0x3003c550, kwdict = 0x3004abb8), line 5142 in "ceval.c" _PyEval_EvalFrameDefault(tstate = 0x, f = 0x300b2268, throwflag = 805759592), line 3603 in "ceval.c" _PyEval_EvalCode(tstate = 0x3005e9d8, _co = 0x30062290, globals = (nil), locals = 0x20026000, args = 0x300ac690, argcount = 805331176, kwnames = 0x2ff20a60, kwargs = 0x422822cf, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8, qualname = 0x300197c8), line 40 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x3005dbac, stack = (nil), nargsf = 805553488, kwnames = 0x30040960), line 417 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x30090e10, throwflag = 804391856), line 628 in "abstract.h" function_code_fastcall(tstate = 0x300a4568, co = 0x3004a1b0, args = 0x2000af50, nargs = 1, globals = 0x3004a688), line 40 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = (nil), f = 0x0001, throwflag = 804392192), line 628 in "abstract.h" function_code_fastcall(tstate = 0x3009116c, co = 0x30031176, args = 0x30031160, nargs = 805622640, globals = (nil)), line 40 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = 0x10075ac4, f = 0x20060d88, throwflag = 804392528), line 628 in "abstract.h" function_code_fastcall(tstate = 0x0094, co = 0x00ab, args = 0x3003c550, nargs = 805702704, globals
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 - wheile researching, so probably, yes. Just do not know it off the top. Atm - testing "master" build using xlc-v11 and xlc-v13. On 06/07/2020 18:13, David Edelsohn wrote: > David Edelsohn added the comment: > > I don't believe that this is an XLC bug, but I suspect that it is undefined > behavior / implementation-defined behavior. > > I suspect that this is tripping over AIX/XLC null behavior. AIX specifically > and intentionally maps the first page of memory at address 0 to allow the > compiler to speculate through NULL pointers. The compiler probably is > speculating in this case and the second element is not defined. > > There is some option to disable this speculation in XLC. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41215> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 bug (that they might call a difference of implementation). I have been testing with xlc-v11; shall also try (your simplified example) using v13 and v16. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41215> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 {
> char *str;
> int type;
> } KeywordToken;
>
> static KeywordToken *the_array[] = {
>NULL,
>NULL,
>(KeywordToken[]) {
> {"if", 510},
> {"in", 518},
> {"as", 520},
> {"is", 527},
> {"or", 532},
> {NULL, -1},
>},
>NULL,
>NULL,
> (KeywordToken[]) {
> {"del11", 503},
> {"try22", 511},
> {NULL, -1},
> },
> NULL
> };
>
>
> int main() {
>for (int s=0; s<7;s++) {
> KeywordToken *tok = the_array[s];
> printf("--> %i\n",s);
> if (tok == NULL) {
> continue;
> }
> printf("--> %i %.*s\n", s,s, tok->str);
>}
>return 0;
> }
>
> [cpython (3.9)]$ xlc check_bad.c -o check_bad
> [cpython (3.9)]$ ./check_bad
> --> 0
> --> 1
> --> 2
> Segmentation fault (core dumped)
>
>
> But if you change it to:
>
> #include
>
> typedef struct {
> char *str;
> int type;
> } KeywordToken;
>
> static KeywordToken *the_array[] = {
> (KeywordToken[]) {{NULL, -1}},
> (KeywordToken[]) {{NULL, -1}},
> (KeywordToken[]) {
> {"if", 510},
> {"in", 518},
> {"as", 520},
> {"is", 527},
> {"or", 532},
> {NULL, -1},
> },
> (KeywordToken[]) {{NULL, -1}},
> (KeywordToken[]) {{NULL, -1}},
> (KeywordToken[]) {
> {"del11", 503},
> {"try22", 511},
> {NULL, -1},
> },
> (KeywordToken[]) {{NULL, -1}},
> };
>
>
> int main() {
>for (int s=0; s<7;s++) {
> KeywordToken *tok = the_array[s];
> if (tok == NULL) {
> continue;
> }
> printf("--> %i %.*s\n", s,s, tok->str);
>}
>return 0;
> }
>
> [cpython (3.9)]$ xlc check.c -o check
> [cpython (3.9)]$ ./check
> --> 0
> --> 1
> --> 2 if
> --> 3
> --> 4
> --> 5 del11
> --> 6
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue41215>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue41215>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35773] test_bdb fails on non-UTF-8 locale
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 "encodings" submodule. There are shortcuts for the UTF-8 > codec which avoid using the Python code. > > -- > nosy: +serhiy.storchaka > title: test_bdb fails on AIX bot (regression) -> test_bdb fails on non-UTF-8 > locale > versions: +Python 3.10, Python 3.9 > > ___ > Python tracker > <https://bugs.python.org/issue35773> > ___ > -- ___ Python tracker <https://bugs.python.org/issue35773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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: > > - What is the error. crash - segmentation error. > - Where does the error happen. During python initialization. > - How to reproduce the error. The error occurs during `make` root@x066:[/data/prj/python/bpo-41215]make xlc_r -g -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O -I../git/bpo-41215/Include/internal -IObjects -IInclude -IPython -I. -I../git/bpo-41215/Include -I/opt/include -DPy_BUILD_CORE -o Parser/pegen/pegen.o ../git/bpo-41215/Parser/pegen/pegen.c xlc_r -g -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -O -I../git/bpo-41215/Include/internal -IObjects -IInclude -IPython -I. -I../git/bpo-41215/Include -I/opt/include -DPy_BUILD_CORE -DGITVERSION="\"`LC_ALL=C `\"" -DGITTAG="\"`LC_ALL=C `\"" -DGITBRANCH="\"`LC_ALL=C `\"" -o Modules/getbuildinfo.o ../git/bpo-41215/Modules/getbuildinfo.c rm -f libpython3.9.a ar rcs libpython3.9.a Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/token.o Parser/pegen/pegen.o Parser/pegen/parse.o Parser/pegen/parse_string.o Parser/pegen/peg_api.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/call.o Objects/capsule.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genericaliasobject.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/interpreteridobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/odictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/picklebufobject.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/ast_opt.o Python/ast_unparse.o Python/bltinmodule.o Python/ceval.o Python/codecs.o Python/compile.o Python/context.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/hamt.o Python/import.o Python/importdl.o Python/initconfig.o Python/marshal.o Python/modsupport.o Python/mysnprintf.o Python/mystrtoul.o Python/pathconfig.o Python/peephole.o Python/preconfig.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pyhash.o Python/pylifecycle.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/bootstrap_hash.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/thread.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/pystrhex.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/_operator.o Modules/_collectionsmodule.o Modules/_abc.o Modules/itertoolsmodule.o Modules/atexitmodule.o Modules/signalmodule.o Modules/_stat.o Modules/timemodule.o Modules/_threadmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/faulthandler.o Modules/_tracemalloc.o Modules/hashtable.o Modules/_peg_parser.o Modules/symtablemodule.o Modules/xxsubtype.o Python/frozen.o ../git/bpo-41215/Modules/makexp_aix Modules/python.exp . libpython3.9.a; xlc_r -g -Wl,-bE:Modules/python.exp -lld -o python Programs/python.o libpython3.9.a -lintl -ldl -lm -lm ./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 /bin/sh: 5242890 Segmentation fault(coredump) make: 1254-004 The error code from the last command is 139. Stop. And can be repeated by just trying to start the executable: root@x066:[/data/prj/python/bpo-41215]./python Segmentation fault(coredu
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 that those are valid types? -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
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.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 would end the loop and "RETURN NAME". One working example... NAMEPTR: 20089d44, name_len:6 strlen(name):4472 name.16s: import aliases token: 20030d30, k_type:500, strlen(k->str):6 k->str.16s: return token: 20030d38, k_type:505, strlen(k->str):6 k->str.16s: assert token: 20030d40, k_type:508, strlen(k->str):6 k->str.16s: global token: 20030d48, k_type:513, strlen(k->str):6 k->str.16s: import RETURN k->type: 513 from k-str.16:import And a failed (abbreviated) that ends with the segmentation error: NAMEPTR: 20089d60, name_len:8 strlen(name): name.16s: _unknown = '--un token: 2000f340, k_type:537120904, strlen(k->str):0 k->str.16s: token: 2000f348, k_type:271488524, strlen(k->str):8 k->str.16s: d z▒ token: 2000f350, k_type:805316552, strlen(k->str):0 k->str.16s: token: 2000f358, k_type:368, strlen(k->str):11 k->str.16s: __setitem__ token: 2000f360, k_type:537120928, strlen(k->str):8 k->str.16s: <▒ z▒ token: 2000f368, k_type:0, strlen(k->str):61 k->str.16s: __setitem__($sel token: 2000f370, k_type:271482672, strlen(k->str):0 k->str.16s: ... token: 2000f730, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f738, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f740, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f748, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f750, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f758, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f760, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f768, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f770, k_type:271810528, strlen(k->str):0 k->str.16s: token: 2000f778, k_type:0, strlen(k->str):0 k->str.16s: token: 2000f780, k_type:271810512, strlen(k->str):4 k->str.16s: real token: 2000f788, k_type:0, strlen(k->str):0 k->str.16s: /bin/sh: 8847524 Segmentation fault(coredump) make: 1254-004 The error code from the last command is 139. Hope this helps. I really do not know 'WHERE' it went wrong. I can only begin by guessing. So, expert guidance is appreciated! -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 strncmp(??, ??, ??) at 0xd011d920 _get_keyword_or_name_type(p = 0x0023, name = warning: Unable to access address 0xd from core (invalid char ptr (0x000d)), name_len = 0), line 503 in "pegen.c" _PyPegen_fill_token(p = 0x1025f138), line 546 in "pegen.c" _PyPegen_expect_token(p = (nil), type = 805759776), line 675 in "pegen.c" _tmp_6_rule@AF486_140(??), line 10251 in "parse.c" _PyPegen_lookahead(positive = 269294544, func = 0x3001da40, p = 0x2ff20f30), line 666 in "pegen.c" compound_stmt_rule@AF476_280(??), line 1232 in "parse.c" statement_rule@AF477_284(??), line 795 in "parse.c" unnamed block in _loop1_2_rule(p = 0x30085830), line 10086 in "parse.c" _loop1_2_rule(p = 0x30085830), line 10086 in "parse.c" statements_rule@AF478_285(??), line 766 in "parse.c" file_rule@AF479_289(??), line 646 in "parse.c" _PyPegen_run_parser(p = 0x30085820), line 916 in "pegen.c" _PyPegen_run_parser_from_string(str = "compile", start_rule = 272032944, filename_ob = 0x20084f68, iflags = 805427776, arena = 0x30085820), line 1024 in "pegen.c" PyPegen_ASTFromStringObject(str = (nil), filename = (nil), mode = 804393472, flags = 0x20035cb0, arena = 0x102453c4), line 26 in "peg_api.c" unnamed block in Py_CompileStringObject(str = "|p^[yN", filename = (nil), start = 0, flags = 0x3007bbc8, optimize = -2147483647), line 1244 in "pythonrun.c" Py_CompileStringObject(str = "|p^[yN", filename = (nil), start = 0, flags = 0x3007bbc8, optimize = -2147483647), line 1244 in "pythonrun.c" builtin_compile_impl(module = (nil), source = 0x2bd8, filename = 0x20063c48, mode = "\320Qf", flags = 1, dont_inherit = 536873648, optimize = 804393760, feature_version = 537275800), line 823 in "bltinmodule.c" builtin_compile(module = 0x2ff21460, args = 0x3007fa78, nargs = 2, kwnames = 0x30007470), line 274 in "bltinmodule.c.h" cfunction_vectorcall_FASTCALL_KEYWORDS(func = 0x100b203c, args = 0x0003, nargsf = 804394000, kwnames = 0x20047844), line 396 in "methodobject.c" PyVectorcall_Call(callable = 0x100b2e10, tuple = 0x20026f40, kwargs = 0x2ff21470), line 255 in "call.c" _PyObject_Call(tstate = 0x100b1d1c, callable = 0x30002870, args = 0x2ff214c0, kwargs = 0x30043fd0), line 265 in "call.c" do_call_core(tstate = 0x0001, func = 0x30094050, callargs = 0x30046428, kwdict = 0x300462e8), line 5054 in "ceval.c" _PyEval_EvalFrameDefault(tstate = 0x3009315c, f = 0x30043e58, throwflag = -261800280), line 3542 in "ceval.c" _PyEval_EvalCode(tstate = 0x3005d820, _co = 0x3003a6a0, globals = 0x2ff216d0, locals = 0x422822cc, args = 0x100b46e4, argcount = 805410760, kwnames = 0x2ff216d0, kwargs = 0x20047844, kwcount = 2, kwstep = 1, defs = (nil), defcount = 0, kwdefs = (nil), closure = (nil), name = 0x300197c8, qualname = 0x300197c8), line 41 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x100d3714, stack = 0x3008ea08, nargsf = 804394848, kwnames = 0x20047844), line 411 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x, f = 0x300834c8, throwflag = 804395040), line 487 in "abstract.h" _PyEval_EvalCode(tstate = 0x300865b0, _co = 0x30061b88, globals = 0x2ff218e0, locals = 0x5328333f, args = 0x10073d54, argcount = 537279560, kwnames = 0x2ff218e0, kwargs = 0x20047844, kwcount = 0, kwstep = 1, defs = (nil), defcount = 0, kwdefs = 0x3006bb90, closure = (nil), name = 0x30061b88, qualname = 0x3004eb10), line 41 in "pycore_ceval.h" _PyFunction_Vectorcall(func = 0x30092f50, stack = 0x30004048, nargsf = 804395376, kwnames = (nil)), line 411 in "call.c" _PyEval_EvalFrameDefault(tstate = 0x100759a4, f = (nil), throwflag = 804395568), line 487 in "abstract.h" function_code_fastcall(tstate = 0x300418bc, co = (nil), args = 0x3000c220, nargs = 805664616, globals = (nil)), line 41 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = 0x100759a4, f = 0x30087c08, throwflag = 804395904), line 487 in "abstract.h" function_code_fastcall(tstate = 0x30086520, co = 0x3004c070, args = 0x2000abe8, nargs = 1, globals = 0x30049ec0), line 41 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = (nil), f = 0x0001, throwflag = 804396240), line 487 in "abstract.h" function_code_fastcall(tstate = 0x3004389c, co = 0x30031176, args = 0x30031160, nargs = 805626736, globals = (nil)), line 41 in "pycore_ceval.h" _PyEval_EvalFrameDefault(tstate = 0x100759a4, f = 0x20063c48, throwflag = 80439
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
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 Galindo Date: Wed Apr 22 23:29:27 2020 +0100 bpo-40334: PEP 617 implementation: New PEG parser for CPython (GH-19503) Co-authored-by: Guido van Rossum Co-authored-by: Lysandros Nikolaou +++ the make status (abbreviated) is: root@x066:[/data/prj/python/py39-3.10]slibclean; rm -rf *; buildaix --without-computed-gotos; print; date; ./python -E -S -m sysconfig --generate-posix-vars; ./python + CPPFLAGS="-I/opt/include" CFLAGS="-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5"\ ../git/py39-3.10/configure\ --prefix=/opt \ --sysconfdir=/var/py39/etc\ --sharedstatedir=/var/py39/com\ --localstatedir=/var/py39\ --mandir=/usr/share/man\ --infodir=/opt/share/info/py39 --without-computed-gotos\ > .buildaix/configure.out + /usr/bin/make > .buildaix/make.out 1500-016: (W) WARNING: Compiler problem occurred while compiling _PyPegen_clear_memo_statistics: A file or directory in the path name does not exist.. 1500-034: (S) Cannot create object file. make: 1254-004 The error code from the last command is 1. +++ The complete make.out (stdout) is: root@x066:[/data/prj/python/py39-3.10]cat .buildaix/make* xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Programs/python.o ../git/py39-3.10/Programs/python.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/acceler.o ../git/py39-3.10/Parser/acceler.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/grammar1.o ../git/py39-3.10/Parser/grammar1.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/listnode.o ../git/py39-3.10/Parser/listnode.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/node.o ../git/py39-3.10/Parser/node.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/parser.o ../git/py39-3.10/Parser/parser.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/token.o ../git/py39-3.10/Parser/token.c xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I../git/py39-3.10/Include/internal -IObjects -IInclude -IPython -I. -I../git/py39-3.10/Include -I/opt/include -I/opt/include -DPy_BUILD_CORE -o Parser/pegen/pegen.o ../git/py39-3.10/Parser/pegen/pegen.c *** After commit a25f3c4c8f7d4878918ce1d3d67db40ae255ccc6 (HEAD) Author: Pablo Galindo Date: Thu Apr 23 01:38:11 2020 +0100 bpo-40334: Fix builds outside the source directory and regenerate autoconf files (GH-19667) /bin/sh: 7405692 Segmentation fault(coredump) make: 1254-004 The error code from the last command is 139. Stop. /usr/bin/make returned an error Sun Jul 5 11:23:39 UTC 2020 Segmentation fault(coredump) Python 3.9.0a5+ (default, Jul 5 2020, 11:23:33) [C] on aix Type "help", "copyright", "credits" or "license" for more information. *** The above includes aixtools@x064:[/data/prj/python/git/py39-3.10]git checkout 458004bf7914f96b20bb76bc3584718cf83f652e Previous HEAD position was a25f3c4c8f bpo-40334: Fix builds outside the source directory and regenerate autocon
[issue40878] Use c99 on the aixtools bot
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 not being built - builds (i.e., compile) fail completely atm. regards, Michael On 15/06/2020 18:55, Michael Felt wrote: > 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 would still be interesting to see what happens if you compile >> libmpdec with c99_r (emphasis mine): >> >> >> """ >> This command supports all ISO >> C99 language features, but does >> not support IBM language >> extensions. Use this invocation for >> *strict* conformance to the C99 >> standard. >> """ >> >> -- >> >> ___ >> Python tracker >> <https://bugs.python.org/issue40878> >> ___ >> > -- > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40680] thread_cputime isn't supported by AIX5
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 AIX 6.1 (e.g., to have _uuid support). In any case, I still package using AIX 6.1 (again, _uuid mod support) and rely on AIX binary compatibility for installations on AIX 7.1 and AIX 7.2. Should you be thinking/considering moving AIX to the "supported" column - I would "gladly" embrace AIX 7.1 as a requirement. On 10/06/2020 22:58, STINNER Victor wrote: > STINNER Victor added the comment: > > According to > https://www.ibm.com/support/pages/aix-support-lifecycle-information I suggest > to require AIX 7.1 and newer. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40680> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
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 with xlc-v11. Although - my last runs on the POWER6, by default, were using gcc - so maybe I thought, incorrectly, that xlc was passing. Time shall tell. p.s. - if you make a PR that emulates a rollback, if that is what you were thinking - I can test that separately/manually. Michael On 16/06/2020 09:04, Michael Felt wrote: > 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! >> >> Ha, it turns out that c99_r has excellent C99 compliance. :) >> >>> Variable arguments macro RAISE_SYNTAX_ERROR was invoked with an empty >>> variable argument list. >> Totally legit, we should use xlc (at least the front end) more often. >> >> >> So maybe our code base is not C99 compliant enough and we have to switch >> back for sanity. >> >> >> >> For the _decimal problem at hand, if you give me the compiler identification >> macro (__xlc__ or something?) I can try the same as for MSVC and use the >> explicit EXTINLINE definition. >> >> -- >> >> ___ >> Python tracker >> <https://bugs.python.org/issue40878> >> ___ >> > -- > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
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! > > Ha, it turns out that c99_r has excellent C99 compliance. :) > >> Variable arguments macro RAISE_SYNTAX_ERROR was invoked with an empty >> variable argument list. > > Totally legit, we should use xlc (at least the front end) more often. > > > So maybe our code base is not C99 compliant enough and we have to switch back > for sanity. > > > > For the _decimal problem at hand, if you give me the compiler identification > macro (__xlc__ or something?) I can try the same as for MSVC and use the > explicit EXTINLINE definition. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
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 would still be interesting to see what happens if you compile > libmpdec with c99_r (emphasis mine): > > > """ > This command supports all ISO > C99 language features, but does > not support IBM language > extensions. Use this invocation for > *strict* conformance to the C99 > standard. > """ > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
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 the pain (e.g., false bot failures and bot report storage impact) asap. Many thanks for looking - and commenting! On 15/06/2020 16:34, Kevin wrote: > Kevin added the comment: > > This seems to be a duplicate of https://bugs.python.org/issue19521 > > The PR for that one seems a little less hacky since it uses make rules to > prevent duplication instead of lock files. > > -- > nosy: +kadler > > ___ > Python tracker > <https://bugs.python.org/issue40424> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
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/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: parallel build and ld WARNINGS
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 -Wl,-bE:Modules/python.exp -lld -o python Programs/python.o libpython3.9d.a -lintl -ldl -lm -lm ./Modules/makexp_aix Modules/python.exp . libpython3.9d.a; gcc -pthread -Wl,-bE:Modules/python.exp -lld -o Programs/_testembed Programs/_testembed.o libpython3.9d.a -lintl -ldl -lm -lm ld: 0711-418 ERROR: Import or export file Modules/python.exp at line 2: A symbol name may only be followed by an export attribute or an address. The line is being ignored. ld: 0711-415 WARNING: Symbol PyAST_Check is already exported. ld: 0711-415 WARNING: Symbol PyAST_Compile is already exported. ld: 0711-415 WARNING: Symbol PyAST_CompileEx is already exported. ld: 0711-415 WARNING: Symbol PyAST_CompileObject is already exported. ... Over 4000 lines of warnings later: ld: 0711-415 WARNING: Symbol _Py_write is already exported. ld: 0711-415 WARNING: Symbol _Py_write_noraise is already exported. collect2: error: ld returned 8 exit status Makefile:598: recipe for target 'python' failed make: *** [python] Error 1 program finished with exit code 2 Explanation: makexp_aix is running in parallel - and writing to python.exp in parallel. The patch/PR "tames" this - and, hopefully, multiple "fails" per day, of the AIX bots will cease. p.s. needed in 3.8, 3.9 and the new master (3.10) -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40680] thread_cputime isn't supported by AIX5
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 unmodified on AIX 7.1 and AIX 7.2 (AIX binary compatibility). FYI. On 19/05/2020 13:57, Batuhan Taskaya wrote: > Batuhan Taskaya added the comment: > > Does AIX 5.3 officially supported by IBM? As far as I can locate, it is > deprecated long time ago. > > -- > nosy: +BTaskaya > > ___ > Python tracker > <https://bugs.python.org/issue40680> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40878] Use c99 on the aixtools bot
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:[/home/buildbot]ls -l /etc/*vac* -rw-r--r-- 1 bin bin 37731 Aug 02 2018 /etc/vac.cfg.53 -rw-r--r-- 1 bin bin 39672 Aug 02 2018 /etc/vac.cfg.61 -rw-r--r-- 1 bin bin 39681 Aug 02 2018 /etc/vac.cfg.71 -rw-r--r-- 1 bin bin 39611 Aug 02 2018 /etc/vac.cfg.72 Herein I see that xlc is "extc99" and some extras: * -qlanglvl=extc99 C compiler with common extensions, UNIX headers xlc: use = DEFLT_C crt = /lib/crt0.o mcrt = /lib/mcrt0.o gcrt = /lib/gcrt0.o libraries = -L/usr/vac/lib,-lxlopt,-lxlipa,-lxl,-lc proflibs = -L/lib/profiled,-L/usr/lib/profiled options = -qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi I have chosen the xlc_r variant - for thread_safe additions: * standard c compiler aliased as xlc_r (61 Threads) xlc_r: use = DEFLT_C crt = /lib/crt0.o mcrt = /lib/mcrt0.o gcrt = /lib/gcrt0.o libraries = -L/usr/vac/lib,-lxlopt,-lxlipa,-lxl,-lpthreads,-lc proflibs = -L/lib/profiled,-L/usr/lib/profiled hdlibs = -L/usr/vac/lib,-lhmd options = -qlanglvl=extc99,-qcpluscmt,-qkeyword=inline,-qalias=ansi,-qthreaded,-D_THREAD_SAFE,-D__VACPP_MULTI__ So, what is c99 then? -> focus on it is 'stdc99' rather than 'extc99' * Strict ANSI compiler, ANSI headers c99: use = DEFLT_C crt = /lib/crt0.o mcrt = /lib/mcrt0.o gcrt = /lib/gcrt0.o libraries = -L/usr/vac/lib,-lxlopt,-lxlipa,-lxl,-lc proflibs = -L/lib/profiled,-L/usr/lib/profiled options = -qlanglvl=stdc99,-D_ANSI_C_SOURCE,-D_ISOC99_SOURCE,-qalias=ansi,-qstrict_induction Hope this helps clarify that both xlc and c99 are "c99" based. Regards, Michael On 05/06/2020 21:34, Stefan Krah wrote: > New submission from Stefan Krah : > > There appears to be an xlc buildbot with libmpdec failures. > > libmpdec uses C99 extern inline semantics. From the brief period that I had > access to xlc I remember that xlc was quite picky about C99. > > Actually all of Python uses C99. So I think xlc_r needs to be invoked as > c99_r. > > -- > messages: 370779 > nosy: Michael.Felt, skrah > priority: normal > severity: normal > status: open > title: Use c99 on the aixtools bot > > ___ > Python tracker > <https://bugs.python.org/issue40878> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39791] New `files()` api from importlib_resources.
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/Lib/test/test_importlib/test_main.py
index 42a7999..7b18c3d 100644
--- a/Lib/test/test_importlib/test_main.py
+++ b/Lib/test/test_importlib/test_main.py
@@ -246,3 +246,19 @@ class TestEntryPoints(unittest.TestCase):
"""
with self.assertRaises(Exception):
json.dumps(self.ep)
+
+def test_module(self):
+assert self.ep.module == 'value'
+
+def test_attr(self):
+assert self.ep.attr is None
+
+
+class FileSystem(fixtures.OnSysPath, fixtures.SiteDir, unittest.TestCase):
+def test_unicode_dir_on_sys_path(self):
+"""
+Ensure a Unicode subdirectory of a directory on sys.path
+does not crash.
+"""
+fixtures.build_files({'☃': {}}, prefix=self.site_dir)
+list(distributions())
AIX bots fail with:
Captured traceback
==
Traceback (most recent call last):
File
"/home/shager/cpython-buildarea/3.9.edelsohn-aix-ppc64/build/Lib/test/test_importlib/test_main.py",
line 263, in test_unicode_dir_on_sys_path
fixtures.build_files({'\u2603': {}}, prefix=self.site_dir)
File
"/home/shager/cpython-buildarea/3.9.edelsohn-aix-ppc64/build/Lib/test/test_importlib/fixtures.py",
line 202, in build_files
full_name.mkdir()
File
"/home/shager/cpython-buildarea/3.9.edelsohn-aix-ppc64/build/Lib/pathlib.py",
line 1309, in mkdir
self._accessor.mkdir(self, mode)
UnicodeEncodeError: 'latin-1' codec can't encode character '\u2603' in position
17: ordinal not in range(256)
Test report
===
Failed tests:
- test_importlib
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39791>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 reverted - I would appreciate it. If no time, I'll get to it as soon as I can. -- ___ Python tracker <https://bugs.python.org/issue40244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40680] thread_cputime isn't supported by AIX5
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../git/python-3.9/Include -I/opt/include -DPy_BUILD_CORE_BUILTIN -DPy_BUILD_CORE_BUILTIN -I../git/python-3.9/Include/internal -c ../git/python-3.9/Modules/timemodule.c -o Modules/timemodule.o "../git/python-3.9/Modules/timemodule.c", line 1358.22: 1506-275 (S) Unexpected text tc encountered. "../git/python-3.9/Modules/timemodule.c", line 1358.5: 1506-045 (S) Undeclared identifier thread_cputime_t. "../git/python-3.9/Modules/timemodule.c", line 1359.29: 1506-045 (S) Undeclared identifier tc. "../git/python-3.9/Modules/timemodule.c", line 1861.19: 1506-196 (W) Initialization between types "void*" and "int(*)(struct _object*)" is not allowed. make: 1254-004 The error code from the last command is 1. -- components: Build, Library (Lib) messages: 369335 nosy: Michael.Felt priority: normal severity: normal status: open title: thread_cputime isn't supported by AIX5 versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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 quick update! -- ___ Python tracker <https://bugs.python.org/issue39148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39148] DatagramProtocol + IPv6 does not work with ProactorEventLoop
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/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/loader.py",
line 436, in _find_test_path
module = self._get_module_from_name(name)
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/loader.py",
line 377, in _get_module_from_name
__import__(name)
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py",
line 239, in
class EventLoopTestsMixin:
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py",
line 1262, in EventLoopTestsMixin
@unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 not supported or enabled')
AttributeError: module 'test.support' has no attribute 'IPV6_ENABLED'
test test_asyncio crashed -- Traceback (most recent call last):
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py",
line 270, in _runtest_inner
refleak = _runtest_inner2(ns, test_name)
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py",
line 234, in _runtest_inner2
test_runner()
File
"/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py",
line 208, in _test_module
raise Exception("errors while loading tests")
Exception: errors while loading tests
1 test failed again:
test_asyncio
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: parallel build and ld WARNINGS
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/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: parallel build and ld WARNINGS
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 party) packaging - MOST of these warnings can be eliminated by ensuring that the export file creation completes before additional steps try to use it. By adding a small test to see if the export file is in the process of being made - and waiting for that to finish - the messages "go away". The PR that is being proposed only affects AIX (a script named makeaix_exp). The script has not been modified in 22 years - so I guess the -j option is something that showed up after 1998 :) I know it is not perfect - but removes a tremendous amount of noise - most of the time. Michael p.s. requesting backport to 3.8 so all buildbots benefit. -- components: Build messages: 367541 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: parallel build and ld WARNINGS type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
Michael Felt added the comment: Thanks for the quick response. I see both bots are good. -- ___ Python tracker <https://bugs.python.org/issue40370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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: > > Tested on an AIX system: > > [pablo@ibm_machine cpython (master)]$ uname -a > AIX ibm_machine 1 7 *** powerpc AIX > [pablo@ibm1 cpython (master)]$ ./python -m test test_peg_generator > 0:00:00 Run tests sequentially > 0:00:00 [1/1] test_peg_generator > > == Tests result: SUCCESS == > > 1 test OK. > > Total duration: 5.0 sec > Tests result: SUCCESS > > I will mark this issue as fixed as It was failing before on this machine and > now the test suceeds. Feel free to reopen if is not fixes in your system :) > > -- > resolution: -> fixed > stage: patch review -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue40370> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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
test_unicode_file_functions test_winconsoleio test_winreg
test_winsound test_zipfile64
0:05:24
0:05:24 Re-running failed tests in verbose mode
0:05:24 Re-running test_peg_generator in verbose mode
test_advanced_left_recursive
(test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_c_parser (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_cut (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_error_in_rules (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_gather (test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_gather_action_ast (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_headers_and_trailer (test.test_peg_generator.test_c_parser.TestCParser)
... ok
test_if_stmt_action (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_left_recursion (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_lookahead (test.test_peg_generator.test_c_parser.TestCParser) ...
/tmp/tmpte0se473/parse.c: In function 'start_rule':
/tmp/tmpte0se473/parse.c:32:35: warning: passing argument 2 of
'_PyPegen_lookahead' from incompatible pointer type
[-Wincompatible-pointer-types]
_PyPegen_lookahead(1, _PyPegen_name_token, p)
^~~
In file included from /tmp/tmpte0se473/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected
'void * (*)(Parser *) {aka void * (*)(struct *)}' but argument is
of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct
*)}'
int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
^~
ERROR
test_mutually_left_recursive
(test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_nasty_mutually_left_recursive
(test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_negative_lookahead (test.test_peg_generator.test_c_parser.TestCParser) ...
/tmp/tmpyyc57e2e/parse.c: In function 'start_rule':
/tmp/tmpyyc57e2e/parse.c:32:35: warning: passing argument 2 of
'_PyPegen_lookahead' from incompatible pointer type
[-Wincompatible-pointer-types]
_PyPegen_lookahead(0, _PyPegen_name_token, p)
^~~
In file included from /tmp/tmpyyc57e2e/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected
'void * (*)(Parser *) {aka void * (*)(struct *)}' but argument is
of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct
*)}'
int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
^~
ERROR
test_pass_stmt_action (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_return_stmt_noexpr_action
(test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_same_name_different_types
(test.test_peg_generator.test_c_parser.TestCParser) ... ERROR
test_syntax_error_for_string
(test.test_peg_generator.test_c_parser.TestCParser) ... []
ERROR
test_ternary_operator (test.test_peg_generator.test_c_parser.TestCParser) ...
ERROR
test_with_stmt_with_paren (test.test_peg_generator.test_c_parser.TestCParser)
... ERROR
test_advance_left_recursion
(test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_alternatives (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_epsilon_production_in_start_rule
(test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_gather (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_left_recursion (test.test_peg_generator.test_first_sets.TestFirstSets) ...
ok
test_multiple_nullable_rules
(test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_mutual_left_recursion
(test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_nasty_left_recursion
(test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_negative_lookahead (test.test_peg_generator.test_first_sets.TestFirstSets)
... ok
test_nullable_rule (test.test_peg_generator.test_first_sets.TestFirstSets) ...
ok
test_optional_after (test.test_peg_generator.test_first_sets.TestFirstSets) ...
ok
test_optional_before (test.test_peg_generator.test_first_sets.TestFirstSets)
... ok
test_optional_literal (test.test_peg_generator.test_first_sets.TestFirstSets)
... ok
test_optional_operator (test.test_peg_generator.test_first_sets.TestFirstSets)
... ok
test_optionals (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_positive_lookahead (test.test_peg_generator.test_first_sets.TestFirstSets)
... ok
test_repeat_0 (test.test_peg_generator.test_first_sets.TestFirstSets) ... ok
test_repeat_0_with_group
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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 -IInclude -IPython -I. -I../git/python-3.9/Include -I/opt/include -DPy_BUILD_CORE -o Modules/_math.o ../git/python-3.9/Modules/_math.c CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp' OPT='-O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ../git/python-3.9/setup.py build make: 1254-059 The signal code from the last command is 11. ** All I can test using PR19674 ** Hope it helps. -- ___ Python tracker <https://bugs.python.org/issue40370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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/issue40370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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 min 49
sec), test_multiprocessing_forkserver (3 min 18 sec),
test_multiprocessing_spawn (2 min 56 sec)
[]
\u2514\u2500\u2500Rule
\u2514\u2500\u2500Rhs
\u2514\u2500\u2500Alt
\u251c\u2500\u2500NamedItem
\u2502 \u2514\u2500\u2500StringLeaf("'a'")
\u2514\u2500\u2500NamedItem
\u2514\u2500\u2500Opt
\u2514\u2500\u2500Rhs
\u2514\u2500\u2500Alt
\u251c\u2500\u2500NamedItem
\u2502 \u2514\u2500\u2500StringLeaf("'b'")
\u2514\u2500\u2500NamedItem
\u2514\u2500\u2500Opt
\u2514\u2500\u2500Rhs
\u2514\u2500\u2500Alt
\u251c\u2500\u2500NamedItem
\u2502 \u2514\u2500\u2500StringLeaf("'c'")
\u2514\u2500\u2500NamedItem
\u2514\u2500\u2500Opt
\u2514\u2500\u2500Rhs
\u2514\u2500\u2500Alt
\u2514\u2500\u2500NamedItem
\u2514\u2500\u2500StringLeaf("'d'")
start() ... (looking at 1.0: OP:'(')
expect('(') ... (looking at 1.0: OP:'(')
... expect('(') -> TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1,
1), line='(1)')
expr() ... (looking at 1.1: NUMBER:'1')
number() ... (looking at 1.1: NUMBER:'1')
... number() -> TokenInfo(type=2 (NUMBER), string='1', start=(1, 1),
end=(1, 2), line='(1)')
... expr() -> [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1,
2), line='(1)')]
expect(')') ... (looking at 1.2: OP:')')
... expect(')') -> TokenInfo(type=54 (OP), string=')', start=(1, 2), end=(1,
3), line='(1)')
... start() -> [TokenInfo(type=54 (OP), string='(', start=(1, 0), end=(1, 1),
line='(1)'), [TokenInfo(type=2 (NUMBER), string='1', start=(1, 1), end=(1, 2),
line='(1)')], TokenInfo(type=54 (OP), string=')', start=(1
Rule('start', None, Rhs([Alt([NamedItem(None, Gather(StringLeaf("','"),
NameLeaf('thing'))), NamedItem(None, NameLeaf('NEWLINE'))])]))
/tmp/tmp9nzhxvu1/parse.c: In function 'start_rule':
/tmp/tmp9nzhxvu1/parse.c:32:35: warning: passing argument 2 of
'_PyPegen_lookahead' from incompatible pointer type
[-Wincompatible-pointer-types]
_PyPegen_lookahead(1, _PyPegen_name_token, p)
^~~
In file included from /tmp/tmp9nzhxvu1/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected
'void * (*)(Parser *) {aka void * (*)(struct *)}' but argument is
of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct
*)}'
int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
^~
/tmp/tmp1qne6lpy/parse.c: In function 'start_rule':
/tmp/tmp1qne6lpy/parse.c:32:35: warning: passing argument 2 of
'_PyPegen_lookahead' from incompatible pointer type
[-Wincompatible-pointer-types]
_PyPegen_lookahead(0, _PyPegen_name_token, p)
^~~
In file included from /tmp/tmp1qne6lpy/parse.c:2:0:
/home/aixtools/python/cpython-master/Parser/pegen/pegen.h:90:5: note: expected
'void * (*)(Parser *) {aka void * (*)(struct *)}' but argument is
of type 'struct _expr * (*)(Parser *) {aka struct _expr * (*)(struct
*)}'
int _PyPegen_lookahead(int, void *(func)(Parser *), Parser *);
^~
test test_peg_generator failed -- multiple errors occurred; run in verbose mode
for details
0:03:47 [417/423/1] test_pathlib passed (3 min 36 sec) -- running: test_bufio
(3 min 35 sec), test_concurrent_futures (3 min 27 sec),
test_multiprocessing_fork (3 min 18 sec), test_subprocess (3 min 6 sec),
test_multiprocessing_forkserver (3 min 35 sec), test_multiprocessing_spawn (3
min 14 sec)
0:03:51 [418/423/1] test_multiprocessing_fork passed (3 min 21 sec) -- running:
test_bufio (3 min 39 sec), test_concurrent_futures (3 min 32 sec),
test_subprocess (3 min 11 sec), test_multiprocessing_forkserver (3 min 40 sec),
test_multiprocessing_spawn (3 min 18 sec)
/home/aixtools/python/cpython-master/Lib/multiprocessing/resource_tracker.py:216:
UserWarning: resource_tracker: There appear to be 1 leaked shared_memory
objects to clean up at shutdown
warnings.warn('resource_tracker: There appear to be %d '
/home/aixtools/python/cpython-master/Lib/multiprocessing/resource_tracker.py:229:
UserWarning: resource_tracker: '/psm_35e4dd20': [Err
[issue40370] AIX: ld_so_aix not found during test of test_peg_generator
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 it to be in a new location, and with a name dependent on being debug (or not) as the bots are configured using --pydebug. Examples: FileNotFoundError: [Errno 2] No such file or directory: '/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/target/lib/python3.9/config-3.9d/ld_so_aix' or FileNotFoundError: [Errno 2] No such file or directory: '/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/target/lib/python3.9/config-3.9d/ld_so_aix' This is (only?) in test_peg_generator. One traceback example: Captured traceback == Traceback (most recent call last): File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_peg_generator/test_c_parser.py", line 174, in test_nasty_mutually_left_recursive self.check_input_strings_for_grammar(grammar, self.tmp_path, valid_cases, invalid_cases) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_peg_generator/test_c_parser.py", line 40, in check_input_strings_for_grammar extension = generate_parser_c_extension(grammar, Path(tmp_path)) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Tools/peg_generator/pegen/testutil.py", line 95, in generate_parser_c_extension extension_path = compile_c_extension(str(source), build_dir=str(path / "build")) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Tools/peg_generator/pegen/build.py", line 73, in compile_c_extension cmd.run() File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 340, in run self.build_extensions() File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 449, in build_extensions self._build_extensions_serial() File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 474, in _build_extensions_serial self.build_extension(ext) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/command/build_ext.py", line 551, in build_extension self.compiler.link_shared_object( File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/ccompiler.py", line 713, in link_shared_object self.link(CCompiler.SHARED_OBJECT, objects, File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/unixccompiler.py", line 204, in link self.spawn(linker + ld_args) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/ccompiler.py", line 910, in spawn spawn(cmd, dry_run=self.dry_run) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/distutils/spawn.py", line 74, in spawn proc = subprocess.Popen(cmd, env=env) File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/subprocess.py", line 947, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/Lib/subprocess.py", line 1819, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: '/home/aixtools/buildarea/3.x.aixtools-aix-power6/build/target/lib/python3.9/config-3.9d/ld_so_aix' See https://buildbot.python.org/all/#builders/119/builds/720 and https://buildbot.python.org/all/#builders/227/builds/723 -- components: Build, Tests messages: 367081 nosy: Michael.Felt priority: normal severity: normal status: open title: AIX: ld_so_aix not found during test of test_peg_generator type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40370> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 _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, !_PyObject_GC_IS_TRACKED(self), > + "object already tracked by they garbage collector", > + __FILE__, __LINE__, "_PyObject_GC_TRACK"); > _PyObject_GC_TRACK(self); > > if (PyObject_CallFinalizerFromDealloc(self)) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40244> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39953] Let's update ssl error codes
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? > > -- > nosy: +SilentGhost > > ___ > Python tracker > <https://bugs.python.org/issue39953> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39953] Let's update ssl error codes
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 wrote: > > > SilentGhost added the comment: > > Michael, could you try with the latest fix in 584a3cfda4? > > -- > nosy: +SilentGhost > > ___ > Python tracker > <https://bugs.python.org/issue39953> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39953] Let's update ssl error codes
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-declaration -fvisibility=hidden -I./Include/internal -I/opt/freeware/include -I./Include -I. -I/home/aixtools/python/cpython-master/Include -I/home/aixtools/python/cpython-master -c /home/aixtools/python/cpython-master/Modules/_ssl.c -o build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o -L/opt/freeware/lib -lssl -lcrypto -o build/lib.aix-7200-1543-32-3.9-pydebug/_ssl.so ld: 0711-317 ERROR: Undefined symbol: .SSL_SESSION_get_ticket_lifetime_hint ld: 0711-317 ERROR: Undefined symbol: .SSL_SESSION_has_ticket ld: 0711-317 ERROR: Undefined symbol: .SSL_session_reused ld: 0711-317 ERROR: Undefined symbol: .COMP_get_type ld: 0711-317 ERROR: Undefined symbol: .SSL_is_init_finished ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_options ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_clear_options ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_set_options ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_is_aead ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_cipher_nid ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_digest_nid ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_kx_nid ld: 0711-317 ERROR: Undefined symbol: .SSL_CIPHER_get_auth_nid ld: 0711-317 ERROR: Undefined symbol: .X509_STORE_get0_objects ld: 0711-317 ERROR: Undefined symbol: .X509_OBJECT_get0_X509 ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_num ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_value ld: 0711-317 ERROR: Undefined symbol: .X509_OBJECT_get_type ld: 0711-317 ERROR: Undefined symbol: .X509_NAME_ENTRY_set ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_default_passwd_cb ld: 0711-317 ERROR: Undefined symbol: .SSL_CTX_get_default_passwd_cb_userdata ld: 0711-317 ERROR: Undefined symbol: .OpenSSL_version_num ld: 0711-317 ERROR: Undefined symbol: .TLS_method ld: 0711-317 ERROR: Undefined symbol: .TLS_client_method ld: 0711-317 ERROR: Undefined symbol: .TLS_server_method ld: 0711-317 ERROR: Undefined symbol: .BIO_up_ref ld: 0711-317 ERROR: Undefined symbol: .OPENSSL_sk_pop_free ld: 0711-317 ERROR: Undefined symbol: .X509_get_version ld: 0711-317 ERROR: Undefined symbol: .X509_getm_notBefore ld: 0711-317 ERROR: Undefined symbol: .X509_getm_notAfter ld: 0711-317 ERROR: Undefined symbol: .OpenSSL_version ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. $ lslpp -L | grep openssl aixtools.openssl.rte 1.0.2.16C Faixtools openssl 27-Aug-2018 openssl.base 1.0.1.515CEFOpen Secure Socket Layer openssl.man.en_US1.0.1.515C FOpen Secure Socket Layer openssl 1.1.0g-1withsslv2C RSecure Sockets Layer and openssl-devel1.1.0g-1withsslv2C RSecure Sockets Layer and +++ FYI +++ IBM AIX used some strange version numbers: 1.0.1.515 is actually an OpenSSL 1.0.2 ABI version. The "aixtools" fileset is 1.0.2p (p == 16th character of alphabet). In any case - the test for X509_VERIFY_PARAM_set1_host() has been passing. -- ___ Python tracker <https://bugs.python.org/issue39953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39953] Let's update ssl error codes
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 the necessary APIs,
https://github.com/libressl-portable/portable/issues/381
messages:
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-declaration -fvisibility=hidden -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/aixtools/python/cpython-master/Modules/_ssl.c -o
build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o
In file included from /home/aixtools/python/cpython-master/Modules/_ssl.c:136:0:
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:650:28: error:
'ERR_LIB_ASYNC' undeclared here (not in a function); did you mean
'ERR_LIB_ASN1'?
{"FAILED_TO_SET_POOL", ERR_LIB_ASYNC, 101},
^
ERR_LIB_ASN1
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:1510:29: error:
'ERR_LIB_CT' undeclared here (not in a function); did you mean 'ERR_LIB_CMS'?
{"BASE64_DECODE_ERROR", ERR_LIB_CT, 108},
^~
ERR_LIB_CMS
/home/aixtools/python/cpython-master/Modules/_ssl_data.h:2650:24: error:
'ERR_LIB_KDF' undeclared here (not in a function); did you mean 'ERR_LIB_BUF'?
{"INVALID_DIGEST", ERR_LIB_KDF, 100},
^~~
ERR_LIB_BUF
--
___
Python tracker
<https://bugs.python.org/issue39953>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39953] Let's update ssl error codes
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/aixtools/python/cpython-master/Modules/_ssl.c -o
build/temp.aix-7200-1543-32-3.9-pydebug/home/aixtools/python/cpython-master/Modules/_ssl.o
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 650.28:
1506-045 (S) Undeclared identifier ERR_LIB_ASYNC.
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 1510.29:
1506-045 (S) Undeclared identifier ERR_LIB_CT.
"/home/aixtools/python/cpython-master/Modules/_ssl_data.h", line 2650.24:
1506-045 (S) Undeclared identifier ERR_LIB_KDF.
"/home/aixtools/python/cpython-master/Modules/_ssl.c", line 579.17: 1506-196
(W) Initialization between types "void*" and "struct _object*(*)(struct
{...}*)" is not allowed.
commit 909b87d2bb3d6330d39c48e43f7f50f4d086cc41
Author: Benjamin Peterson
Date: Sun Apr 12 13:59:31 2020 -0500
closes bpo-39953: Generate ifdefs around library code definitions.
(GH-19490)
commit 3e0dd3730b5eff7e9ae6fb921aa77cd26efc9e3a
Author: Benjamin Peterson
Date: Sat Apr 11 15:36:12 2020 -0500
closes bpo-39953: Update OpenSSL error codes table. (GH-19082)
I updated the error codes using the OpenSSL 1.1.1f source tree.
commit 173ad83b074b3bf0c9e86eb8bd101c2841f74297
Author: Antoine Pitrou
Date: Sun Jan 18 17:39:32 2015 +0100
Issue #23248: Update ssl error codes from latest OpenSSL git master.
commit f7338f65fb8bdb85c52dc54d06d003a82a06bbb3
Author: Antoine Pitrou
Date: Fri Jun 22 21:12:59 2012 +0200
Add forgotten files for #14837.
$
--
nosy: +Michael.Felt
___
Python tracker
<https://bugs.python.org/issue39953>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 prints but about re-compiling? >> (just guessing). > I only recompiled the one .c file. With that one file re-compiled - > wqith fprintf statements it succeeds, restore the original .c file (git > checkout -- Objects/whatever.c; make - it fails. > > Tomorrow I'll search for the option(s) needed to get (complete) assembly > code listing and try to see (and understand) the difference between what > xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile > only this one file using xlc-v13 and see if the make then proceeds normally. > > Many pages of output - and I confess - I do have some difficulty reading code every now and then. As the "bug" wherever it may be is related, I am guessing, to compiler optimization and how to deal with routines with "no return". Trying to understand the listings - I ran across: ./Include/object.h:typedef void (*destructor)(PyObject *); Could the error be related to compilers confusing a routine with no return, versus a routine returning a pointer to a "void"? recall the code: static void gen_dealloc(PyGenObject *gen) Comments? Michael > As Victor commented earlier - very much looking like a compiler bug. > That said, still do not know what to say/write to software support as a > complaint. > >> -- >> >> ___ >> Python tracker >> <https://bugs.python.org/issue40244> >> ___ >> > -- > > ___ > Python tracker > <https://bugs.python.org/issue40244> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 file. With that one file re-compiled - wqith fprintf statements it succeeds, restore the original .c file (git checkout -- Objects/whatever.c; make - it fails. Tomorrow I'll search for the option(s) needed to get (complete) assembly code listing and try to see (and understand) the difference between what xlc-v13 and xlc-v16 makes. And, what I shall also test - is to recompile only this one file using xlc-v13 and see if the make then proceeds normally. > Because I experienced when I compile python for the first time on a clean > AIX environment, all extension modules failed to build. I only see this happen (on occasion) when I use make -j4 (or greater) - and I have seen it happen to a lessor extent with -j2. On the subsequent passes, whatever it is that setup.py (guessing) really needs is now available - and the modules build as expected. This is also why, for the last 4 years I have used my own personal server - where I control everything (mainly NO other party OSS packaged software and their artifacts). > When I recompiled (with keeping all artifacts from previous build) some of > them successfully got compiled. When I try to compile again, most of them > successfully compiled. I'm sorry but I don't know why this happens or how to > solve it. why - I do not understand the finer details either, but my guess is that it is related to linking. I am nearly "amazed" - yet happy - that the PPC64 AIX 3.X compile succeeds - but acknowledge the 22K+ lines of warnings is related to the over parallelization of the linking. > We can always revert that change but I guess that isn't the real problem. 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 help the optimizer make "informed" decisions. As Victor commented earlier - very much looking like a compiler bug. That said, still do not know what to say/write to software support as a complaint. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40244> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40244> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
*)(op)-1)->_gc_next != 0)" failed: object already tracked by the garbage
collector
Enable tracemalloc to get the memory block allocation traceback
object address : 30084150
object refcount : 0
object type : 20013718
object type name: generator
object repr :
Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: core initialized
Current thread 0x0001 (most recent call first):
File "", line 1593 in _setup
File "", line 1634 in _install
File "", line 1189 in
_install_external_importers
/bin/sh: 17302202 IOT/Abort trap(coredump)
make: 1254-004 The error code from the last command is 134.
Stop.
$ git diff
diff --git a/Objects/genobject.c b/Objects/genobject.c
index d3455f8..e783636 100644
--- a/Objects/genobject.c
+++ b/Objects/genobject.c
@@ -119,7 +119,7 @@ gen_dealloc(PyGenObject *gen)
{
PyObject *self = (PyObject *) gen;
- _PyObject_GC_UNTRACK(gen);
+ _PyObject_GC_UNTRACK(self);
if (gen->gi_weakreflist != NULL)
PyObject_ClearWeakRefs(self);
$
On 14/04/2020 00:18, Batuhan Taskaya wrote:
> 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 (gen->gi_weakreflist != NULL)
> PyObject_ClearWeakRefs(self);
> _PyObject_GC_TRACK(self);
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue40244>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue40244>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
Objects/genobject.c:126:0
Objects/genobject.c:131:0
Objects/genobject.c:135:537318120
Objects/genobject.c:122:805942488
Objects/genobject.c:126:0
Objects/genobject.c:131:0
Objects/genobject.c:135:537318120
...
diff --git a/Objects/genobject.c b/Objects/genobject.c
index d3455f8..b8287a3 100644
--- a/Objects/genobject.c
+++ b/Objects/genobject.c
@@ -117,14 +117,23 @@ exc_state_clear(_PyErr_StackItem *exc_state)
static void
gen_dealloc(PyGenObject *gen)
{
+#include
PyObject *self = (PyObject *) gen;
+ fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+ fflush(stderr);
_PyObject_GC_UNTRACK(gen);
+ fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+ fflush(stderr);
if (gen->gi_weakreflist != NULL)
PyObject_ClearWeakRefs(self);
+ fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+ fflush(stderr);
_PyObject_GC_TRACK(self);
+ fprintf(stderr,"%s:%d:%ld\n", __FILE__,__LINE__,
_Py_AS_GC(self)->_gc_next);
+ fflush(stderr);
if (PyObject_CallFinalizerFromDealloc(self))
return; /* resurrected. :( */
$
On 13/04/2020 23:19, Batuhan Taskaya wrote:
> 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 != NULL)
> PyObject_ClearWeakRefs(self);
> <<<<
> _PyObject_GC_TRACK(self);
>
>
> something like this should work: printf("%ld\n", _Py_AS_GC(self)->_gc_next);
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue40244>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue40244>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracemalloc to get the memory block allocation traceback object address : 30084150 object refcount : 0 object type : 20013710 object type name: generator object repr : Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed Python runtime state: core initialized Current thread 0x0001 (most recent call first): File "", line 1593 in _setup File "", line 1634 in _install File "", line 1189 in _install_external_importers ksh: 22151670 IOT/Abort trap(coredump) See attached file for the script capture. On 11/04/2020 15:13, Batuhan Taskaya wrote: > 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]: /opt/IBM/xlc/16.1.0/bin/xlc_r > sysconfig[CFLAGS]: -DNDEBUG -O > sysconfig[CONFIG_ARGS]: 'CC=/opt/IBM/xlc/16.1.0/bin/xlc_r' > sysconfig[OPT]: -DNDEBUG -O > sysconfig[PY_CFLAGS]: -DNDEBUG -O > sysconfig[PY_CFLAGS_NODIST]: -I./Include/internal > sysconfig[PY_STDMODULE_CFLAGS]: -DNDEBUG -O -I./Include/internal -I. > -I./Include > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40244> > ___ > -- Added file: https://bugs.python.org/file49058/issue40170.txt ___ Python tracker <https://bugs.python.org/issue40244> ___Script command is started on Mon Apr 13 06:29:37 CDT 2020. $ .kxlc16-envc166xlc16 $ echo $PATH $CC /opt/IBM/xlc/16.1.0/bin:/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java7_64/jre/bin:/usr/java7_64/bin:/home/aixtools/bin xlc_r $ updategit Checking out files: 100% (160/160), done. Previous HEAD position was 0003c2d... bpo-40096: Support __attribute__((__noreturn__)) on xlc (GH-19204) Switched to branch 'master' Your branch is up-to-date with 'upstream/master'. remote: Enumerating objects: 610, done.K remote: Counting objects: 100% (610/610), done.K remote: Compressing objects: 100% (2/2), done.K remote:nTotale775:(delta(608),7reused 609 (delta 608), pack-reused 165K Receiving objects: 100% (775/775), 533.45 KiB | 0 bytes/s, done. Resolving deltas: 100% (645/645), completed with 287 local objects. >From https://github.com/python/cpython 38aefc5..0c13e1f master -> upstream/master 8a0a500..7a41638 2.7-> upstream/2.7 44c1cdd..0a9ec9f 3.7-> upstream/3.7 f7b0259..ee691b0 3.8-> upstream/3.8 * [new tag] v2.7.18rc1 -> v2.7.18rc1 >From https://github.com/python/cpython * branchmaster -> FETCH_HEAD Updating 38aefc5..0c13e1f Checking out files: 100% (195/195), done. Fast-forward Doc/c-api/gcsupport.rst | 18 Doc/howto/unicode.rst | 5 Doc/library/dis.rst | 6 Doc/library/multiprocessing.rst | 13 Doc/library/socket.rst | 11 Doc/library/ssl.rst | 3 Doc/library/threading.rst | 8 - Doc/whatsnew/3.9.rst| 28 Include/Python.h| 1 Include/cpython/abstract.h | 10 Include/cpython/objimpl.h | 111 Include/cpython/pystate.h | 7 Include/errcode.h | 1 Include/genericaliasobject.h| 14 Include/internal/pycore_abstract.h | 22 Include/internal/pycore_ceval.h | 11 Include/internal/pycore_gc.h| 69 ++ Include/internal/pycore_interp.h| 183 Include/internal/pycore_object.h| 11 Include/internal/pycore_pymem.h
[issue40112] AIX: xlc - default path changed and no longer recognized
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 > <https://bugs.python.org/issue40112> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
