David Edelsohn added the comment:
It seems that PyOS_AfterFork_Child() needs to do something like
PyThreadState *tstate = PyThreadState_Get();
PyObject *wr = _PyObject_CAST(tstate->on_delete_data);
PyObject *obj = PyWeakref_GET_OBJECT(wr);
lockobject *lock;
if (obj != Py_None) {
l
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue43665>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Edelsohn added the comment:
How could release_sentinel() be structured to not call PyThread_release_lock()?
This seems to be a situation where _PyThreadState_DeleteExcept() is deleting
all thread states. thread__set_sentinel() sets release_sentinel() as its
on_delete hook. The thread
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue40068>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue40092>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Edelsohn added the comment:
Christian,
The Python Community Code of Conduct also states:
Being respectful of differing viewpoints and experiences.
Showing empathy towards other community members.
Various developers are passionate about this topic and the entire series of
comments has
David Edelsohn added the comment:
Victor: https://en.wikipedia.org/wiki/31-bit_computing :-)
--
___
Python tracker
<https://bugs.python.org/issue43179>
___
___
David Edelsohn added the comment:
I am not aware of significant use of 31 bit mode.
But I don't see the benefit of annoying and discouraging users who want to
experiment with Python and with Linux on Z in 31 bit mode. Yes, maintenance
theoretically is a burden, but there have been
David Edelsohn added the comment:
gcc -dM -E - < /dev/null
--
Added file: https://bugs.python.org/file49818/gcc-s390x.txt
___
Python tracker
<https://bugs.python.org/issu
David Edelsohn added the comment:
gcc -m31 -dM -E - < /dev/null
--
Added file: https://bugs.python.org/file49817/gcc-s390.txt
___
Python tracker
<https://bugs.python.org/issu
David Edelsohn added the comment:
I understand the issue is s390, not s390x. I am offering that there already is
an s390x worker, so would it be sufficient to build and test Python in 31 bit
mode on that worker as opposed to installing a complete s390 Debian system
David Edelsohn added the comment:
I already am running a Debian s390x buildbot for Python. Someone can adjust
the rules for the buildbot to include a 31-bit builder. The Debian buildbot
has relatively few builder variants relative to the other s390x targets
David Edelsohn added the comment:
This has nothing to do with AIX.
This conversation should include Charalampos Stratakis, but I don't see him as
an option for Nosy.
It probably is easy to add a s390 31-bit build to one of the buildbots.
--
nosy: -aixto...@gmail.com
David Edelsohn added the comment:
I believe that Michael was trying to probe under what circumstances the failure
appears. But, not GCC 4.7 is not relevant.
--
___
Python tracker
<https://bugs.python.org/issue42
David Edelsohn added the comment:
I investigated another problem with nextafter() in 2015 and opened an internal
IBM AIX PMR. At the time it was not using decimal float code.
The earlier problem was the handling of -0.0. At the time, the code was
hand-written assembly language that did
David Edelsohn added the comment:
I think that it is reasonable to drop support for AIX 5.3.
--
___
Python tracker
<https://bugs.python.org/issue42087>
___
___
David Edelsohn added the comment:
nextafter is a known problem on AIX. I believe that it is being addressed in
newer releases of AIX.
Michael and I are helping the IBM AIX Open Source team to increase their
attention on Python, but things only move so fast
David Edelsohn added the comment:
If Python has been defaulting to dlopen() on AIX systems that support it, there
is no reason to maintain the historical, AIX-specific load() support in
dynload_aix.c
I believe that dlopen() was introduced on AIX in release 4.3. The official end
of support
Change by David Edelsohn :
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue41401>
___
___
Python-bugs-list mailing list
Unsubscribe:
David Edelsohn added the comment:
It's the same system. It doesn't fail alone. Didn't we both previously see
issues with the interaction of tests due to the other of tests, that previous
tests left things in the environment that affected later tests
David Edelsohn added the comment:
Bisection failed after 101 iterations and 0:20:29
--
___
Python tracker
<https://bugs.python.org/issue41717>
___
___
Python-bug
David Edelsohn added the comment:
I have updated
edelsohn-aix-ppc64
edelsohn-debian-z
edelsohn-fedora-ppc64
edelsohn-fedora-rawhide-z
edelsohn-fedora-z
edelsohn-rhel-z
edelsohn-rhel8-z
edelsohn-sles-z
aixtools-aix-power6
--
___
Python tracker
David Edelsohn added the comment:
I can provide some information from the logs of one of the buildbots, or change
a parameter. Let me know.
--
___
Python tracker
<https://bugs.python.org/issue41
David Edelsohn added the comment:
I have found a large number of un-removed files in /tmp. Things seem to
function better with Buildbots running older 0.x "buildslave" as opposed to
newer "builtbot-worker" instances.
--
nosy: +David.Edelsohn
title: Buildbot: wo
David Edelsohn added the comment:
If they want to discuss here, fine, but the failing bot is a symptom not the
problem. The Buidlbot infrastructure is unstable, causing disconnects and
leaving un-removed files. If one looks at the workers, one can see many of the
architectures
David Edelsohn added the comment:
It really would be better to discuss this in the builtbot mailing list and not
Python issue tracker.
I have been seeing problems with many buildbots for the past few weeks, not
just the s390x bots. I receive messages that all of the bots disconnected
David Edelsohn added the comment:
Yes, export file generation still is required.
Python does not need to utilize runtime linking. Using -G is a very bad choice
and severely discouraged with severe performance and other penalties.
--
___
Python
David Edelsohn added the comment:
> About PSALLOC=early , I confirm that it perfectly fixes the issue.
> I'm surprised, because it is unspeakably slow on this machine,
These statements are not contradictory. No one is suggesting that Python
always should run with PSALLOC
David Edelsohn added the comment:
Yes, it doesn't appear that it will be solved in libffi. I don't fully
understand the need for the work-around because it should gracefully overflow
to the stack. I can't tell if the issue is a problem with arguments passed by
value that need to be passed
David Edelsohn added the comment:
AIX uses a "late" memory allocation scheme by default. If the test wants to
malloc(52631578947368422ULL) and intends it to fail, it should run with the AIX
$ export PSALLOC=early
environment variable. More than all of the other maxdata changes.
David Edelsohn added the comment:
AIX systems at OSUOSL have been part of the GNU Compile Farm for a decade. It
also is the system on which I have been running the Python Buildbot. Any
Compile Farm user has access to AIX.
https://cfarm.tetaneutral.net/users/new/
Also, IBM
David Edelsohn added the comment:
Core developers have full access to AIX system for the asking. Back to you,
Stefan.
--
___
Python tracker
<https://bugs.python.org/issue41
David Edelsohn added the comment:
+Eryksun,Vinay
The patch to address array passing described in issue #22273 introduced
regressions for other targets. The 16 byte struct size is specific to x86 ABI
and register passing convention. I appreciate that the 16-32 byte size
structure causes
David Edelsohn added the comment:
As mentioned in the stgdict.c comment, this relates back to #22273 and #29565.
The passing of arrays/structs is fragile, to use a euphemism. The ctypes
behavior conforms to the x64 Linux ABI and x64 libffi, even the comment from
#22273,
"St
David Edelsohn added the comment:
The example with memchr() never will be correct because it is invalid to call a
function with an argument list that doesn't match the function signature.
Your comment mentions that the AIX structure is size 16, but it looks like
Python calculates the AIX
David Edelsohn added the comment:
I thought that the ctypes documentation mentioned that Arrays passed by Value
are converted to Structures. I cannot find it in the ctypes documentation at
the moment. But Modules/_ctypes/stgdict.c has a large comment about passing
Arrays by Value
David Edelsohn added the comment:
Tony, Please see my reply from 2020-02-05. This is a known "bug" in Python
ctypes. This is documented in Python ctypes. This will not be fixed. This
cannot be fixed.
Python ctypes converts the array to a structure and creates an incorr
David Edelsohn added the comment:
Maybe XLC was being overly aggressive with speculation and it now is fixed. I
can't tell if Michael's earlier comment meant that it no longer crashes with
XLC v16.
--
___
Python tracker
<https://bugs.python.
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
David Edelsohn added the comment:
Likely somewhere in the Python configuration process it is probing a command
line option that emits a .lst file.
--
___
Python tracker
<https://bugs.python.org/issue40
David Edelsohn added the comment:
The bug report implies a different bug than what is being reported. The bug is
not related to calling a LIBC function with an argument list that does not
match the function signature.
The true issue is that a Python ctypes structure definition on AIX
David Edelsohn added the comment:
Is this a legal use of Python ctypes? I don't see anything in the Python
documentation that one can call a ctypes function with an argument list that
does not match the function signature and expect it to work. Maybe this works
on x86 by accident
David Edelsohn added the comment:
How was Python compiled? With GCC? Which version of GCC?
I assume that Python was built as a 64 bit application based on libc loading
the 64 bit member shr_64.o.
Does the testcase work in 32 bit mode?
Does the testcase work if Python is compiled by XLC
David Edelsohn added the comment:
I think that Victor means AIX kernel and filesystems are not prepared for Y2038.
--
nosy: +David.Edelsohn
___
Python tracker
<https://bugs.python.org/issue39
Change by David Edelsohn :
--
nosy: +David.Edelsohn, Michael.Felt
___
Python tracker
<https://bugs.python.org/issue38628>
___
___
Python-bugs-list mailin
David Edelsohn added the comment:
In utime_stat_localtime.py, "os.stat (sec)" is the result of os.utime.
In utime_stat_localtime2.py "os.stat (sec int)" is the result of os.stat.
--
___
Python tracker
<https://bug
David Edelsohn added the comment:
[dje@rawhide ~]$ touch testfn
[dje@rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800,
4386268800))'
[dje@rawhide ~]$ stat testfn
File: testfn
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd
David Edelsohn added the comment:
Not -O3, but it's calling PyLong_FromLongLong on s390x as well
0x011ca524 <+28>:brasl %r14,0x10649b0
--
___
Python tracker
<https://bugs.python.org/i
David Edelsohn added the comment:
$ ./python utime_stat_localtime2.py
os.utime (sec): 4386268800
os.stat (sec int): 2147483647
os.stat (sec float): 2147483647.0
os.stat (ns): 21474836470
--
___
Python tracker
<https://bugs.python.
David Edelsohn added the comment:
$ ./python
Python 3.9.0a3+ (heads/master:aabdeb766b, Jan 28 2020, 13:50:48)
[GCC 10.0.1 20200121 (Red Hat 10.0.1-0.4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> impor
David Edelsohn added the comment:
Output on s390x Fedora Rawhide:
$ ./python utime_stat_localtime.py
os.utime (sec): 4386268800
os.stat (sec): 4386268800
os.stat (ns): 21474836470
stat==utime? False
localtime: (2038, 1, 18, 22, 14, 7
David Edelsohn added the comment:
Do you believe that a single GCC 10 issue is affecting PPC64LE, ARM, and s390x,
but expressed in different manners on the different architectures OR is the
PPC64LE issue separate and architecture-depdendent
David Edelsohn added the comment:
Sorry, posted the wrong output above.
$ ./python -m test test_zipfile
0:00:00 load avg: 0.01 Run tests sequentially
0:00:00 load avg: 0.01 [1/1] test_zipfile
test test_zipfile failed -- Traceback (most recent call last):
File "/home/dje/src/cpython/Lib
David Edelsohn added the comment:
$ ./python -m test tet_zipfile
0:00:00 load avg: 0.03 Run tests sequentially
0:00:00 load avg: 0.03 [1/1] tet_zipfile
test tet_zipfile crashed -- Traceback (most recent call last):
File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py"
David Edelsohn added the comment:
The file was created and owned by another user. I have removed the file. I
have reached out to the user to find out why he is creating it.
--
___
Python tracker
<https://bugs.python.org/issue39
David Edelsohn added the comment:
Runtime linking allows a dynamically loaded library to interpose symbols. The
classic example is allowing a program or dynamic library to overload C++
operator new. A library or program overrides the symbol by name.
Python does not require this. Python does
David Edelsohn added the comment:
Absolutely, positively no. This is horrible and completely wrong.
Applications on AIX should not be compiled to allow dynamic linking to make
them operate more like SVR4/Linux. Python does not require dynamic linking.
This simply is masking a symptom
David Edelsohn <dje@gmail.com> added the comment:
The AIX buildbots has been exhibiting testsuite failures, but not build
(compile) failures. The buildbots do not visibly distinguish between the two
cases in a strong manner.
We can disable / expect failure for the few, addi
David Edelsohn <dje@gmail.com> added the comment:
_ALL_SOURCE is overkill. It probably is too big a club for this regression.
However, the AIX header definition of fsid compatible with the current Python
posixmodule.c code is bracketed by _ALL_SOURCE.
AFAICT, the change to posixmo
Change by David Edelsohn <dje@gmail.com>:
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27435>
___
Change by David Edelsohn <dje@gmail.com>:
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10656>
___
Change by David Edelsohn <dje@gmail.com>:
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28009>
___
David Edelsohn <dje@gmail.com> added the comment:
/* typedef for the File System Identifier (fsid). This must correspond
* to the "struct fsid" structure in _ALL_SOURCE below.
*/
typedef struct fsid_t {
#ifdef __64BIT_KERNEL
unsigned long val[2];
#else /
David Edelsohn <dje@gmail.com> added the comment:
struct statvfs {
ulong_tf_bsize; /* preferred file system block size */
ulong_tf_frsize;/* fundamental file system block size*/
fsblkcnt_t f_blocks;/* total # of blocks of f_
Change by David Edelsohn <dje@gmail.com>:
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28290>
___
Change by David Edelsohn <dje@gmail.com>:
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue27643>
___
David Edelsohn added the comment:
I completely agree with Martin's concern. As I expressed before, this needs to
work in three contexts:
1) Building modules in the tree during the build process.
2) In-tree testing of build module feature (test_distutils).
3) Building and installing modules
David Edelsohn added the comment:
Michael, you need to build from scratch. The values are set and tweaked in
various phases of configure and then written to _sysconfigdata.py for
installation.
The values in the file reflect the values used during the build, but many of
them are not used
David Edelsohn added the comment:
There is an AIX system in the Python buildbot farm. Why do you say no AIX to
test?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
Michael Felt,
The patch was from Michael Haubenwallner. I was addressing Michael
Haubenwallner.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
Michael,
Are you suggesting to move the code fragment *AND* revert or change the
reversal of LDSHARED? The Python code seems to be setting and reversing the
value in multiple places.
This also relates to Issue25825.
Repeatedly flipping this around
David Edelsohn added the comment:
I believe that everything is functioning correctly.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
$(BINLIBDEST)/config is equivalent to $(LIBPL) in Python 2.7, so Python 2.7
should be okay.
Patch2 will not make test_distutils results worse, but the test results may not
represent the true status of distutils on AIX if the matching Python version
David Edelsohn added the comment:
> This bug was marked for 2.7 as well. Is there anything that needs to be done
> for 2.7?
It would be great if both patches were applied to 2.7 also.
> How does patch 2 make the test_distutils situation worse? Is there anything
> that sh
David Edelsohn added the comment:
The second of two patches. This patch changes the definition of LDSHARED for
AIX in configure to reference the matching installed location as defined in
Makefile.pre.in by Patch1. The definition from configure propagates into
_sysconfigdata.py.
This change
David Edelsohn added the comment:
Yes, please apply Patch 1 that reverts the mistaken change of revision
88a532a31eb3 . I want to work through this incrementally so that it's clear to
reviewers.
--
___
Python tracker <rep...@bugs.python.org>
David Edelsohn added the comment:
Let's start with this patch to revert the change mentioned in msg256136 to look
for python.exp in Modules -- the test, the source for the file, and the
location to delete the file.
A follow-up patch will fix the data in _sysconfigdata.py.
--
Added
David Edelsohn added the comment:
I have updated the fingerprint in .hgrc.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
These look like false positives or noise to me as well.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
The most recent patch seems to follow AIX semantics correctly.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
It's not symbol with value 0, it's symbol number 0. You can list the symbols
with the AIX "dump -t" command.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.py
David Edelsohn added the comment:
Something is building libpython2.7.a incorrectly or the python.exp script is
not functioning correctly.
ld: 0711-596 SEVERE ERROR: Object libpython2.7.a[ceval.o]
An RLD for section 2 (.data) refers to symbol 0,
but the storage class
David Edelsohn added the comment:
Don't use XLC. It may relate to using -Wl option, which is a GCC option.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
David Edelsohn added the comment:
AIX traditionally used member names like shr.o or shr.o or
shr.o insider the archive, with _64 designating a 64 bit object
when there is a naming collision.
GNU libtool defaults to the SO name and version number insider the archive.
AIX objects (and shared
David Edelsohn added the comment:
ctypes util.py "simply" needs support for AIX. There already is special
support for Windows, Darwin, BSDs, Solaris. Is the question about the
technical details for equivalent functionality on AIX or about adding a stanza
to Lib/ctpy
David Edelsohn added the comment:
$(prefix) and $(exec_prefix) result in the same path on AIX, so it does not
matter in practice, although the semantics are different.
# Install prefix for architecture-dependent files
exec_prefix=${prefix}
python.exp is not architecture dependent
New submission from David Edelsohn:
AIX requires helper scripts to build Python shared extension modules. The
definitions and Makefile installation rules have bitrotted.
Makefile.pre.in:
@if [ -s Programs/python.exp -a \
except python.exp is created in Modules/python.exp
Changes by David Edelsohn <dje@gmail.com>:
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25825>
___
__
David Edelsohn added the comment:
Misc/README.AIX comments about XLC do not apply to GCC.
One can adjust the memory space at normal link time with
-Wl,-bmaxdata:0xN000. This trades off heap for shared memory segments. One
does not need the extra ldedit stop, which stuffs the same value
David Edelsohn added the comment:
As we have seen with similar issues on other targets, this likely is due to the
random order of tests. In another case, the timezone was not being restored
properly by GLIBC. Another test is leaving the process in a state that somehow
evokes this failure
David Edelsohn added the comment:
The system has 128GB of memory. The process limits are set to unlimited for
data. AIX defaults to 32 bit, although all processors are 64 bit, so the
buildbot runs as 32 bit. What does low free memory in the buildbot mean?
I'm surprised that Python requires
David Edelsohn added the comment:
PPC64 is not a strict alignment system. The system is running a non-recent
release of Fedora, so it could be a bad interaction with libc.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by David Edelsohn dje@gmail.com:
--
nosy: +David.Edelsohn -David Edelsohn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24054
David Edelsohn added the comment:
Also
http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/2/steps/test/logs/stdio
http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/2
Comments
Issue #24054: decouple linecache tests from inspect tests
Patch from David D
David Edelsohn added the comment:
This patch causes a new failure on many of the buildbots.
--
nosy: +David Edelsohn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24054
David Edelsohn added the comment:
A Python3 installation will not overwrite a Python2 installation because they
are different major releases and not completely compatible. If Firefox needs
Python2, you should build the latest, stable release of Python 2.7.
I previously used AIX workstations
David Edelsohn added the comment:
When you configure Python, you can specify an installation directory, which
defaults to /usr/local. make install will overwrite the Python installation
in the specified (possibly default) installation location, but not versions
installed in other locations
David Edelsohn added the comment:
The errors are of the form:
==
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
David Edelsohn added the comment:
The Python testsuite does not produce completely clean results on AIX. You can
see the AIX tester for comparison. Some are caused by assumptions in the
testcases that are correct for Linux but not for some Unix systems, and some
are caused by incorrect
David Edelsohn added the comment:
There now are two zLinux buildbots: zlinux (running SUSE) and zwheezy (running
Debian). zlinux (running on SUSE) has the libc problem causing the timezone
error. A second buildbot was added, not converting or upgrading the existing
buildbot.
I still would
1 - 100 of 248 matches
Mail list logo
