[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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) {
lock = (lockobject *) obj;
if (lock->locked) {
/* Leak memory on purpose. */
lock->locked = 0;
}
}
before the call to _PyEval_ReInitThreads.
Maybe encapsulate that as PyThread_ReInitThreads().
The locks in the threads in the child need to be cleared before
_PyThreadState_DeleteExcept() so that Python does not try to release the locks
in the child.
--
___
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)
Change by David Edelsohn : -- nosy: +David.Edelsohn ___ 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
[issue40092] Crash in _PyThreadState_DeleteExcept() at fork in the process child
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 state is being deleted, release_sentinel() is called
and discovers that the lock is still held.
if (lock->locked) {
PyThread_release_lock(lock->lock_lock);
Do you suggest something like _PyThread_at_fork_reinit() and leak the memory?
To not release the lock in the thread of the child process?
--
___
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
[issue40068] test_threading: ThreadJoinOnShutdown.test_reinit_tls_after_fork() crash with Python 3.8 on AIX
Change by David Edelsohn : -- nosy: +David.Edelsohn ___ Python tracker <https://bugs.python.org/issue40068> ___ ___ 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
Change by David Edelsohn : -- nosy: +David.Edelsohn ___ 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
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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 been respectful, IMHO. I don't believe that it is helpful when you cherry-pick a rule from the code of conduct in response to someone providing additional evidence. That is intimidation and shutting down the conversation with an implicit threat. You specifically mentioned m68k when you opened the issue. This conversation feels very much that you and Victor have pre-determined an outcome and are not open to other points of view. I and others have proposed compromises, but the response appears, at least to me, as shifting requirements. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
David Edelsohn added the comment: Victor: https://en.wikipedia.org/wiki/31-bit_computing :-) -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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 no recent issues that were specific to Linux on Z in 31 bit mode. In fact, most of the original Linux on Z support issues that I opened were endianness issues, which aren't ameliorated by removing 31 bit support. As others have expressed, deprecating 31 bit mode only removes the configuration option with no other code simplification. It seems that it would be better to leave the configuration alone until there actually was an unresolved issue that motivated removal. But I am not aware of any client requirement to continue the support. Leaving the 31 bit configuration unchanged is more about maintaining good will among the volunteers who are interested in the platform. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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? -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
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. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
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 ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ 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
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/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
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 not check for IEEE floating point corner cases. -- ___ 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
[issue42087] Remove pre-AIX 6.1 dead code paths
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> ___ ___ 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
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. -- ___ 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
[issue42030] Drop support for dynload_aix
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 for AIX 4.3 was 2003, so I doubt there are any customers on extended support, or at least those customers are unlikely to install Python 3.11. -- ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ 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
Change by David Edelsohn : -- nosy: +David.Edelsohn ___ 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
[issue41717] [AIX] test_io: files was modified by test_io: (@test_6488748_tmpæ) on POWER6 AIX 3.9
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? -- ___ Python tracker <https://bugs.python.org/issue41717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41717] [AIX] test_io: files was modified by test_io: (@test_6488748_tmpæ) on POWER6 AIX 3.9
David Edelsohn added the comment: Bisection failed after 101 iterations and 0:20:29 -- ___ Python tracker <https://bugs.python.org/issue41717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] Buildbot: workers detached every minute and "no space left on device" issue
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 <https://bugs.python.org/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] Buildbot: workers detached every minute and "no space left on device" issue
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/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] RHEL and fedora buildbots fail due to disk space error
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: workers detached every minute and "no space left on device" issue -> RHEL and fedora buildbots fail due to disk space error ___ Python tracker <https://bugs.python.org/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41648] edelsohn-* buildbot worker failing with: No space left on device
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 in Exception states. I would appreciate a discussion of the underlying issue and not "edelsohn-* buildbot workers failing". -- ___ Python tracker <https://bugs.python.org/issue41648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41648] edelsohn-* buildbot worker failing with: No space left on device
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, but the bots themselves are fine. I also find many temporary files left in the bots, filling the /tmp filesystem. I believe that something else has degraded. -- ___ Python tracker <https://bugs.python.org/issue41648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19521] Parallel build race condition on AIX since python-2.7
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 tracker <https://bugs.python.org/issue19521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41540] Test test_maxcontext_exact_arith (_decimal) consumes all memory on AIX
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=early. -- ___ Python tracker <https://bugs.python.org/issue41540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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 partially in registers and partially in the stack. But if the work-around is necessary, it is target- and ABI-dependent: the number of arguments passed in registers is target- and ABI-dependent. Implementing a work-around solely based on x64 ABI is not correct. The ctypes stgdict.c code needs to define MAX_STRUCT_SIZE based on the target, at least for the targets that experience the problem. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41540] Test test_maxcontext_exact_arith (_decimal) consumes all memory on AIX
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. Separate from all of this, you are configuring as 64 bit (-q64). -qmaxmem affects the compiler optimization. -Wl,-bmaxdata:0x8 is a GCC command line option. "-Wl," passes the appended flag to the linker. So somehow you're using GCC to invoke the linker, although building with XLC. XLC knows about -bmaxdata directly. On the other hand, -bmaxdata behaves differently in 32 bit mode and 64 bit mode. In 32 bit mode, it increases the heap size from the default 256MB. In 64 bit mode, it sets a guaranteed maximum size for the heap. So I think that -bmaxdata may be helping, but not for the reason that you believe. -Wl,-bmaxdata:0x8000 may work, although I don't understand how that correctly interacts with XLC. If you truly are running in 64 bit mode, then -bmaxdata has an effect like PSALLOC. I sort of think that the solution desired for the testcase is PSALLOC=early to match traditional Unix/Linux malloc() behavior. -- ___ Python tracker <https://bugs.python.org/issue41540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41540] Test test_maxcontext_exact_arith (_decimal) consumes all memory on AIX
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 is in the process of creating a dedicated VM at OSUOSL for the Python Buildbot to support more builders. We probably can provide access to Python core members to log in to that system as well. -- ___ Python tracker <https://bugs.python.org/issue41540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41540] Test test_maxcontext_exact_arith (_decimal) consumes all memory on AIX
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/issue41540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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 an abort for x64, but the patch shifted the problem to other targets that now produce wrong code. The later comments in discussion thread for issue #22273 refer to patches that disable and reenable ctypes struct tests for ARMv7 and PPC, so this regression is not a surprise. stgdict.c currently includes a target-specific work-around for small structures that is not restricted to the one target (x64) affected. What's the best way to proceed? -- nosy: +eryksun, vinay.sajip ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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, "Structs that are larger than 32 bytes get copied to the stack (see classify_argument in ffi64.c), so we don't have to worry about classifying their elements for register passing. Thus if a new field is added for this in StgDictObject, then PyCArrayType_new should only allocate it for array types that are 32 bytes or less. Using it for larger array types would serve no point. And now we're at the crux of the problem. I don't know what Ronald and others recommend. ctypes is choosing x64 behavior to define an inherently target-dependent and ABI-dependent design decisions. The real solution requires that _ctypes/stgdict.c incorporate target-specific logic, but it's not clear that the Python community wants to go down that path. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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 structure size as 24 bytes. Have you tried increasing the value of MAX_STRUCT_SIZE in stgdict.c to 32 or 64, corresponding to the argument registers available in 32 bit or 64 bit mode? -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in 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 as Structs. * See bpo-22273. Arrays are normally treated as pointers, which is * fine when an array name is being passed as parameter, but not when * passing structures by value that contain arrays. On 64-bit Linux, * small structures passed by value are passed in registers, and in * order to do this, libffi needs to know the true type of the array * members of structs. Treating them as pointers breaks things. The comment proceeds to discuss 64-bit Linux, which means x86_64 Linux. Python ctypes coerces the array into a structure, which works on x86_64 Linux. Something about the libffi descriptor created by Python ctypes does not work correctly for AIX, and it may be a fundamental difference in the alignment and padding rules for passing Arrays versus Structures. Python ctypes assumes that Arrays and Structures are interchangeable with respect to argument passing. And, again, the initial example was completely wrong and illegal and not expected to work because it created a data object that doesn't match the function signature, which happened to behave correctly on x86. The initial example in the bug report repeatedly confuses people because they continually try to debug an incorrect use of ctypes. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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 incorrect libffi descriptor. The call to libffi creates a "fake" descriptor (description of the arguments) that doesn't match the actual data. It cannot work. This should be closed as "wont fix". -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ 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
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.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
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-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40069] Clear .lst files for AIX
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/issue40069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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 that
contains an array as in the example does not create an argument list that
matches the AIX ABI for argument passing. An example that directly uses libffi
seems to work, but invoking libffi via Python ctypes does not.
In other words, Python ctypes structures created with _fields_ equivalent to
struct {
const char *s;
unsigned long d;
size_t n;
}
should produce the same argument list as
struct {
const char *s;
unsigned long c_n[2];
}
but the version with the array does not.
libffi passes arrays as pointers, so Python ctypes converts arrays passed by
value as libffi structs. This occurs in cpython/Modules/_ctypes/stgdict.c .
It is likely that ctypes is not generating the correct libffi descriptor.
The memchr example visually demonstrates the incorrect argument list, but is
not intended to be correct, safe use of ctypes.
--
___
Python tracker
<https://bugs.python.org/issue38628>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in 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, but that doesn't mean that it is guaranteed to work everywhere and is permitted. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
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? This likely is an incompatibility in libffi with libffi loading the registers incorrectly for the call into libc.a(shr_64.o). It seems rather fragile to pass a struct that is supposed to have the same parameter layout as the function signature. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
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/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
Change by David Edelsohn : -- nosy: +David.Edelsohn, Michael.Felt ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
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://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
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: fd00h/64768dInode: 17887487Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1001/ dje) Gid: ( 1001/ dje)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2038-01-18 22:14:07.0 -0500
Modify: 2038-01-18 22:14:07.0 -0500
Change: 2020-01-28 21:19:14.707112199 -0500
Birth: 2020-01-28 21:19:01.627112199 -0500
[dje@rawhide ~]$ python3 -c 'import os; st=os.stat("testfn"); print(st);
print(tuple(st)); print(st.st_mtime_ns)'
os.stat_result(st_mode=33204, st_ino=17887487, st_dev=64768, st_nlink=1,
st_uid=1001, st_gid=1001, st_size=0, st_atime=2147483647, st_mtime=2147483647,
st_ctime=1580264354)
(33204, 17887487, 64768, 1, 1001, 1001, 0, 2147483647, 2147483647, 1580264354)
21474836470
--
___
Python tracker
<https://bugs.python.org/issue39460>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
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/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
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.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x: time.localtime() limited to year 2038
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. >>> import time >>> time.localtime(2**31) time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0) >>> time.localtime(2**31-3600*24) time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0) >>> time.localtime(2**32) time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0) >>> time.localtime(2**33) time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1) -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
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) -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
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? -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
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/test/test_zipfile.py", line 620, in test_add_file_after_2107 self.assertRaises(struct.error, zipfp.write, TESTFN) AssertionError: error not raised by write test_zipfile failed in 55.6 sec == Tests result: FAILURE == 1 test failed: test_zipfile Total duration: 55.6 sec Tests result: FAILURE -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
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", line 270, in _runtest_inner refleak = _runtest_inner2(ns, test_name) File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2 the_module = importlib.import_module(abstest) File "/home/dje/src/cpython/Lib/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1021, in _gcd_import File "", line 998, in _find_and_load File "", line 975, in _find_and_load_unlocked ModuleNotFoundError: No module named 'test.tet_zipfile' tet_zipfile failed == Tests result: FAILURE == 1 test failed: tet_zipfile Total duration: 76 ms Tests result: FAILURE -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39248] test_distutils fails on PPC64 Fedora 3.x: /tmp/subprocess.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/issue39248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37690] Simplify linking of shared libraries on the AIX OS
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 not need to allow an extension module to override a function in Python. If one needs to add AIX ld -G and runtime linking, 99% of the time one is covering up a problem. The downside of -G is that it forces all global functions to be called through the AIX glink code (equivalent to SVR4 PLT) and not inlined. This allows every global function call to be overriden, but forces every call to go through a function pointer. This is expensive. Calling functions through the "PLT" requires that the function pointers for each global function be placed in the AIX TOC (equivalent to SVR4 GOT). If the program or shared library is large enough, this can overflow the "GOT", which then requires even more expensive fixup code. The mistaken use of this option leads down a path with bad performance and potentially requiring more and more effort to recover from problems introduced by the choice. I don't know exactly the symptoms that you observed, but one possibility is that the shared object you are building is not being linked against all of the dependent libraries. Separate from runtime linking, SVR4 allows unresolved symbols when a shared library is created and used to export all global symbols by default (before the efforts on symbol visibility). A simplistic way of describing this is that a process into which an executable and shared libraries are loaded sort of has this soup of all global symbols floating around and available to the runtime loader. When a new shared library is loaded, the dynamic linker can resolve the symbols from any definitions available in the process. Allowing the unresolved symbols at shared library link time is a promise that the symbols will be provided by someone at runtime. At runtime, all of the symbol needs and definitions are thrown in the air and hopefully match up correctly when first referenced at runtime. AIX requires that all shared objects be fully resolved at link-edit time. It requires that the shared object refer to all dependent libraries at link time, even if those libraries also will be present and provided by other shared libraries or executable at runtime. In other words, on AIX, one must link all C++ shared objects against the C++ standard library, even if the main executable is linked against the library. So, again, one possible explanation for the error of missing symbols is that one or more dependent libraries are missing from the link command building the shared object and that omission coincidentally happens to work on SVR4/Linux because of its semantics, but it doesn't work in the more strict environment of AIX. This type of error should not be solved through runtime linking to borrow the missing symbols from the running process, which is a very expensive solution. -- ___ Python tracker <https://bugs.python.org/issue37690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37690] Simplify linking of shared libraries on the AIX OS
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 in a naive and incorrect manner. Use of runtime linking causes many internal changes to the behavior of AIX applications, severely affecting performance and potentially causing overflow of data structures. We currently are going through the process of removing this brain damage from CMake. I absolutely will not allow Python to go down this path and introduce this type of mistake. -- ___ Python tracker <https://bugs.python.org/issue37690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
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, additional testcases on AIX so that the buildbots will report "success" to make new failures more obvious. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32390] AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
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 posixmodule.c made assumptions about fsid based on Linux and not required by POSIX. This didn't simply introduce a testsuite regression, but broke the build on AIX. The posixmodule.c code should be corrected or should be reverted. -- nosy: +vstinner title: AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed -> AIX compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27435] ctypes library loading and AIX - also for 2.7.X (and later)
Change by David Edelsohn <dje@gmail.com>: -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10656] "Out of tree" build fails on AIX
Change by David Edelsohn <dje@gmail.com>: -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28009] core logic of uuid.getnode() is broken for AIX - all versions
Change by David Edelsohn <dje@gmail.com>: -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
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 /* __64BIT_KERNEL */
#ifdef _ALL_SOURCE
unsigned int val[2];
#else /* _ALL_SOURCE */
unsigned int __val[2];
#endif /* _ALL_SOURCE */
#endif /* __64BIT_KERNEL */
} fsid_t;
#ifdef _KERNEL
typedef struct fsid32_t {
unsigned int val[2];
} fsid32_t;
#endif /* __64BIT_KERNEL */
typedef struct fsid64_t {
#if defined(_ALL_SOURCE) && (defined(__64BIT__) || defined(_LONG_LONG))
uint64_t val[2];
#else /* _ALL_SOURCE */
uint32_t __val[4];
#endif /* _ALL_SOURCE */
} fsid64_t;
/* typedef for the File System Identifier (fsid) */
struct fsid {
#ifndef __64BIT_KERNEL
unsigned intval[2];
#else
unsigned long val[2];
#endif
};
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32390] AIX (xlc_r) compile error with Modules/posixmodule.c: Function argument assignment between types "unsigned long" and "struct fsid_t" is not allowed
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_frsize in fs */
fsblkcnt_t f_bfree; /* total # of free blocks*/
fsblkcnt_t f_bavail;/* # of blocks available to non super user */
fsfilcnt_t f_files; /* total # of file nodes (inode in JFS) */
fsfilcnt_t f_ffree; /* total # of free file nodes*/
fsfilcnt_t f_favail;/* # of nodes available to non super user*/
#ifdef _ALL_SOURCE
fsid_t f_fsid; /* file system id*/
#else
ulong_tf_fsid; /* file system id*/
#ifndef __64BIT__
ulong_tf_fstype;/* file system type */
#endif
#endif /* _ALL_SOURCE */
char f_basetype[_FSTYPSIZ]; /* Filesystem type name (eg. jfs) */
ulong_tf_flag; /* bit mask of flags */
ulong_tf_namemax; /* maximum filename length */
char f_fstr[32]; /* filesystem-specific string */
ulong_tf_filler[16];/* reserved for future use */
};
--
nosy: +David.Edelsohn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32390>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28290] BETA report: Python-3.6 build messages to stderr: AIX and "not GCC"
Change by David Edelsohn <dje@gmail.com>: -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28290> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27643] test_ctypes fails on AIX with xlc
Change by David Edelsohn <dje@gmail.com>: -- nosy: +David.Edelsohn ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
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 with an installed version of Python. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
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 in an installed version of Python. Three important phases are: 1) Building modules in the tree during the build process. 2) In-tree testing of build module feature. 3) Building and installing modules with an installed version of Python. The initial configuration scripts must match the location where the export files will be installed. And the _sysconfigdata.py definitions used to build external modules in an installed version of Python must refer to the proper location. All of the pieces are interconnected and must be tested in a wholistic manner. A partial rebuild does not test the impact of the patch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28845] Clean up known issues for AIX
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/issue28845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
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/issue18235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18235] _sysconfigdata.py wrong on AIX installations
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 is not making progress. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
David Edelsohn added the comment: I believe that everything is functioning correctly. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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 is not installed so that the test can find the files in the installed location. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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 should be done to improve things first, or should that just be handled > independently? I see that the 2.7 and 3.5 buildbots are currently failing > with errors like distutils.errors.LinkError: command './Modules/ld_so_aix' failed with exit status 1 while 3.6 is failing with distutils.errors.LinkError: command '/usr/local/lib/python3.6/config/ld_so_aix' failed with exit status 1 Presumably the 3.6 failure may be helped by Patch 2, since it is complaining about the plain “config” path. Patch2 makes test_distutils worse because LDSHARED refers to a file that only exists when Python is installed. If one tests in tree, the files don't exist. This may be related to the existence of BLDSHARED, used to build modules in the source tree, which can be overridden separately -- otherwise it defaults to LDSHARED. If the rest of the testsuite ever is cleaned up for AIX, one either could skip the parts of test_distutils that require the LDSHARED files or add special hooks in the test for AIX. As you point out, the change doesn't make the current testsuite results situation any worse. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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 will (further) break test_distutils, but the testcase is wrong on AIX. And, for AIX, a correct test result clearly does not correspond to correct behavior. The patch affects both configure.ac and configure because the corresponding change to configure is obvious. The person who installs the patch may regenerate configure, as appropriate. -- Added file: http://bugs.python.org/file44096/Issue25825-patch2.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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 file: http://bugs.python.org/file44068/Issue25825-patch1.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27421] PPC64LE Fedora 2.7: certificate for hg.python.org has unexpected fingerprint
David Edelsohn added the comment: I have updated the fingerprint in .hgrc. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27421> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22463] Warnings when building on AIX
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/issue22463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
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/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26466] cannot build python 2.7.11 on AIX
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.python.org/issue26466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26466] cannot build python 2.7.11 on AIX
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 of the symbol is not C_EXT or C_HIDEXT. 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 of the symbol is not C_EXT or C_HIDEXT. is different than the later undefined symbols error. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26466] cannot build python 2.7.11 on AIX
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/issue26466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
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 objects) contain a bit in the header that specifies 32 bit or 64 bit. Both 32 bit and 64 bit objects are intended to be archived together. The linker only processes objects of the correct mode. AIX shared objects contain a bit that specifies if the object may be used at link-edit time or only should be used for loading. This is controlled by the AIX strip -e/-E option (yes, I know, strange place to hide that option). This combination of features allows all of the libraries to be placed in a single /usr/lib directory and all of the objects to be collected into a single archive, avoiding /usr/lib64 and explosion of shared objects and symbolic links clutter. Various packages have created /usr/local/lib64 anyway using Linux/Solaris/SVR4-style naming. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
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/ctpyes/util.py? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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, although it only is useful on AIX
target. It is essentially equivalent to a list of symbols with ELF global,
non-hidden visibility. It is less confusing if the list is co-located with the
scripts that use it.
LIBPL is fine with me. configure.ac and Makefile.pre.in must match.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
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, not Programs.exp $(INSTALL_DATA) Programs/python.exp \ $(DESTDIR)$(LIBPL)/python.exp; Post-substitution Makefile.pre: BINLIBDEST= $(LIBDIR)/python$(VERSION) LIBDEST=$(SCRIPTDIR)/python$(VERSION) LIBPL= $(LIBDEST)/config-$(LDVERSION) configure.ac: AIX*) BLDSHARED="\$(srcdir)/Modules/ld_so_aix \$(CC) -bI:\$(srcdir)/Modules/python.exp" LDSHARED="\$(BINLIBDEST)/config/ld_so_aix \$(CC) -bI:\$(BINLIBDEST)/config/python.exp" which is forever enshrined in _sysconfigdata.py In other words, configure sets LDSHARED to $(BINLIBDEST)/config, which does not exist in current installations. And Makefile installs the files in LIBPL, which is based on LIBDEST (prefix and exec_prefix could be different). And the files are not installed, because the installation tests Programs/python.exp instead of Modules/python.exp. Changing Makefile.pre.in to test Modules/python.exp is easy enough as a partial fix. What is the preferred location to install the files so that configure.ac and Makefile.pre.in can be adjusted to match each other? -- components: Installation messages: 256123 nosy: David.Edelsohn priority: normal severity: normal status: open title: AIX shared library extension modules installation broken type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25825] AIX shared library extension modules installation broken
Changes by David Edelsohn <dje@gmail.com>: -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] Intermittent segfaults on PPC64 AIX 3.x
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 into the application header. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] Intermittent segfaults on PPC64 AIX 3.x
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 from test_decimal. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
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 a huge amount of memory for the tests. It's possible that Python needs to be built with special options to allow additional malloc space (-bmaxdata:0xN000). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25029] MemoryError in test_strptime
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.python.org/issue25029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
Changes by David Edelsohn dje@gmail.com: -- nosy: +David.Edelsohn -David Edelsohn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
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. Riddle Changed files Lib/test/test_linecache.py -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x)
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23457] make test failures
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, but now access AIX servers remotely from Linux workstations. If you log in remotely to an AIX system, you can access all of your scripts. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23457] make test failures
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 on the systems. The focus of AIX is as a server system, not a deskside system with a graphical user interface. AIX also has many differences from Linux and other SVR4 systems in the way that libraries and shared libraries are built and linked. Firefox is a very complicated application and I doubt that you will have a lot of success building and running it on AIX. If you really need Firefox web browser on your AIX desktop, I strongly suggest that you run Firefox on another system and use the display option to instruct the window to appear on the AIX X Window System. In other words, you can have the web browser appear on the AIX system display without running the web browser on the AIX system. If you need access to local files, you can mount the AIX filesystems on the remote system running the web browser. The Python testsuite errors probably are not the cause of your Firefox build problems. And fixing Python or trying to build Firefox on AIX probably are not effective use of your time and not the best way to solve the real problem of access to a web browser on an AIX display. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22844] test_gdb failure on Debian Wheezy for Z
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 -- Traceback (most recent call last): File /mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py, line 470, in test_NULL_ob_type 'set v-ob_type=0') File /mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py, line 441, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File /mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py, line 227, in get_gdb_repr import_site=import_site) File /mnt/DREAMStorage/dje/cpython-buildarea/3.x.edelsohn-zwheezy-z/build/Lib/test/test_gdb.py, line 205, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: ['warning: Could not load shared library symbols for linux-vdso64.so.1.'] != [] First list contains 1 additional elements. First extra element 0: warning: Could not load shared library symbols for linux-vdso64.so.1. - ['warning: Could not load shared library symbols for linux-vdso64.so.1.'] + [] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22844 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23457] make test failures
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 behavior of corner cases in AIX system libraries. Python works on AIX and should work for your purposes to build Firefox. I don't understand why you think that the problems must be fixed for you to make progress on your project. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23457 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20220] TarFile.list() outputs wrong time
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 appreciate the patch from Issue22844 to fix the test_gdb failure on the zwheezy buildbot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20220 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
