Tony Reix added the comment:
Hi Stefan,
In your message https://bugs.python.org/issue41540#msg375462 , you said:
"However, instead of freezing the machine, the process gets a proper SIGKILL
almost instantly."
That's probably due to a very small size of the Paging Space of the A
Tony Reix added the comment:
I forgot to say that this behavior was not present in stable version 3.8.5 .
Sorry.
On 2 machines AIX 7.2, testing Python 3.8.5 with:
+ cd /opt/freeware/src/packages/BUILD/Python-3.8.5
+ ulimit -d unlimited
+ ulimit -m unlimited
+ ulimit -s unlimited
+ export
Tony Reix added the comment:
Is it a 64bit AIX ? Yes, AIX is 64bit by default and only since ages, but it
manages 32bit applications as well as 64bit applications.
The experiments were done with 64bit Python executables on both AIX and Linux.
The AIX machine has 16GB Memory and 16GB Paging
Tony Reix added the comment:
Hi Pablo,
I'm only surprised that the maximum size generated in the test is always lower
than the PY_SSIZE_T_MAX. And this appears both on AIX and on Linux, which both
compute the same values.
On AIX, it appears (I've just discovered this now) that malloc() does
Tony Reix added the comment:
Some more explanations.
On AIX, the memory is controlled by the ulimit command.
"Global memory" comprises the physical memory and the paging space, associated
with the Data Segment.
By default, both Memory and Data Segment are limited:
# ulimit -a
dat
New submission from Tony Reix :
Python master of 2020/08/11
Test test_maxcontext_exact_arith (test.test_decimal.CWhitebox) checks that
Python correctly handles a case where an object of size 421052631578947376 is
created.
maxcontext = Context(prec=C.MAX_PREC, Emin=C.MIN_EMIN, Emax
Tony Reix added the comment:
I do agree that the example with memchr is not correct.
About your suggestion, I've done it. With 32. And that works fine.
All 3 values are passed by value.
# cat Pb-3.8.5.py
#!/usr/bin/env python3
from ctypes import *
mine = CDLL('./MemchrArgsHack2.so
Tony Reix added the comment:
After more investigations, we (Damien and I) think that there are several
issues in Python 3.8.5 :
1) Documentation.
a) AFAIK, the only place in the Python ctypes documentation where it talks
about how arrays in a structure are managed appears at:
https
Tony Reix added the comment:
Fedora32/x86_64 : Python v3.8.5 : optimized : uint type.
If, instead of using ulong type, the Pb.py program makes use of uint, the issue
is different: see below.
This means that the issue depends on the length of the data.
BUILD=optimized
TYPE=int
export
Change by Tony Reix :
--
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue38628>
___
___
Python-bugs-list mailing list
Unsub
Tony Reix added the comment:
Fedora32/x86_64 : Python v3.8.5 has been built.
Issue is still there, but different in debug or optimized mode.
Thus, change done in https://bugs.python.org/issue22273 did not fix this issue.
./Pb-3.8.5-debug.py :
#!/opt/freeware/src/packages/BUILD/Python-3.8.5
Tony Reix added the comment:
After adding traces and after rebuilding Python and libffi with -O0 -g -gdwarf,
it appears that, still in 64bit, the bug is still there, but that ffi_call_AIX
is called now instead of ffi_call_DARWIN from ffi_call() routine of
../src/powerpc/ffi_darwin.c (lines
Tony Reix added the comment:
On AIX 7.2, with libffi compiled with -O0 -g, I have:
1) Call to memchr thru memchr_args_hack
#0 0x091b0d60 in memchr () from /usr/lib/libc.a(shr_64.o)
#1 0x0900058487a0 in ffi_call_DARWIN () from
/opt/freeware/lib/libffi.a(libffi.so.6)
#2
Tony Reix added the comment:
# pwd
/opt/freeware/src/packages/BUILD/libffi-3.2.1
# grep -R ffi_closure_ASM *
powerpc-ibm-aix7.2.0.0/.libs/libffi.exp: ffi_closure_ASM
powerpc-ibm-aix7.2.0.0/include/ffitarget.h:void * code_pointer; /*
Pointer to ffi_closure_ASM */
src/powerpc
Tony Reix added the comment:
AIX: difference between 32bit and 64bit.
After the second print, the stack is:
32bit:
#0 0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
#1 0xd438f480 in ffi_call_AIX () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2 0xd438effc in ffi_call () from /opt
Tony Reix added the comment:
On AIX in 32bit, we have:
Thread 2 hit Breakpoint 2, 0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
(gdb) where
#0 0xd01407e0 in memchr () from /usr/lib/libc.a(shr.o)
#1 0xd438f480 in ffi_call_AIX () from /opt/freeware/lib/libffi.a(libffi.so.6)
#2
Tony Reix added the comment:
On Fedora/PPC64LE, where it is OK, the same debug with gdb gives:
(gdb) where
#0 0x77df03b0 in __memchr_power8 () from /lib64/libc.so.6
#1 0x7fffea167680 in ?? () from /lib64/libffi.so.6
#2 0x7fffea166284 in ffi_call () from /lib64/libffi.so.6
Tony Reix added the comment:
On Fedora/x86_64, in order to get the core, one must do:
coredumpctl -o /tmp/core dump /usr/bin/python3.8
--
___
Python tracker
<https://bugs.python.org/issue38
Tony Reix added the comment:
On AIX:
root@castor4## gdb /opt/freeware/bin/python3
...
(gdb) run -m pdb Pb.py
...
(Pdb) n
b'def'
> /home2/freeware/src/packages/BUILD/Python-3.8.5/32bit/Pb.py(35)()
-> print(
(Pdb) n
> /home2/freeware/src/packages/BUILD/Python-3.8.5/32bit
Tony Reix added the comment:
Fedora32/x86_64
[root@destiny10 tmp]# gdb /usr/bin/python3.8 core
...
Core was generated by `python3 ./Pb.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7f898a02a1d8 in __memchr_sse2 () from /lib64/libc.so.6
Missing separate debuginfos
Tony Reix added the comment:
On Fedora32/PPC64LE (5.7.9-200.fc32.ppc64le), with little change:
libc = CDLL('/usr/lib64/libc.so.6')
I get the correct answer:
b'def'
b'def'
b'def'
# python3 --version
Python 3.8.3
libffi : 3.1-24
On Fedora32/x86_64 (5.7.9-200.fc32.x86_64), with a little
21 matches
Mail list logo
