This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Got SEGV in compilation python3.6 with GCC-11, and please renewal python3.6.
Type: crash Stage: resolved
Components: Installation Versions: Python 3.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: Nojima Takahide, ned.deily
Priority: normal Keywords:

Created on 2021-11-03 08:54 by Nojima Takahide, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (2)
msg405588 - (view) Author: Nojima Takahide (Nojima Takahide) Date: 2021-11-03 08:54
I found python3.6.15(latest) caused SEGV while installing it using pyenv with GCC-11 on Debian sid. I show the Error below,

---------------here-----------------------
$ pyenv install -k 3.6.15
Downloading Python-3.6.15.tar.xz...
-> https://www.python.org/ftp/python/3.6.15/Python-3.6.15.tar.xz
Installing Python-3.6.15...

BUILD FAILED (Debian unstable using python-build 2.1.0-12-g5963dc4f)

Inspect or clean up the working tree at ~/.anyenv/envs/pyenv/sources/3.6.15
Results logged to /tmp/python-build.20211103135942.18999.log

Last 10 log lines:
if test "xupgrade" != "xno"  ; then \
        case upgrade in \
                upgrade) ensurepip="--upgrade" ;; \
                install|*) ensurepip="" ;; \
        esac; \
         ./python -E -m ensurepip \
                $ensurepip --root=/ ; \
fi
Segmentation fault
make: *** [Makefile:1102: install] Error 139
$ gcc -v
...snip...
gcc version 11.2.0 (Debian 11.2.0-10) 
--------------Here------------------------

This root cause is the same as bpo-27987. In the case of python 3.6.15, the "gcc-11 -O3" applies "movaps" against the non-16bytes alignment address of "PyObject."  I show this clue as below,

--------------Here-----------------------
$ gdb --args ./python -m ensurepip
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6be957e in PyCFuncPtr_new (type=0x555555c3cde8, args=0x7ffff6c6c630, kwds=0x0)
    at ~/.anyenv/envs/pyenv/sources/3.6.15/Python-3.6.15/Modules/_ctypes/_ctypes.c:3557
3557        self->thunk = thunk;
(gdb) disas PyCFuncPtr_new
   ...snip
   0x00007ffff6be955d <+221>:   je     0x7ffff6be98a0 <PyCFuncPtr_new+1056>
   0x00007ffff6be9563 <+227>:   mov    0x78(%rsp),%rax
   0x00007ffff6be9568 <+232>:   movq   %r15,%xmm0
   0x00007ffff6be956d <+237>:   movq   %rax,%xmm1
   0x00007ffff6be9572 <+242>:   addq   $0x1,(%rax)
   0x00007ffff6be9576 <+246>:   mov    0x10(%r13),%rax
   0x00007ffff6be957a <+250>:   punpcklqdq %xmm1,%xmm0
   0x00007ffff6be957e <+254>:   movaps %xmm0,0x60(%r13) ;<- cause SEGV
   0x00007ffff6be9583 <+259>:   mov    0x20(%r15),%rdx
   0x00007ffff6be9587 <+263>:   mov    %rdx,(%rax)

Checking %r13 at "movaps",it has non-16bytes alignment address as its value.
------------------Here------------------

 Then, I would much appriciate if someone does ``cherry-pick`` the following 2 commits of github.com/python/cpython to its branch 3.6,  
  - 8766cb74e186d3820db0a855ccd780d6d84461f7 
  - f0be4bbb9b3cee876249c23f2ae6f38f43fa7495
and please releases the newer python3.6. I already apply and tested this in my Debian box and I confirmed  it to solve this problem.

Thanks.

 Note: For someone who met the same problem, I show two tiny workarounds as below, if no one can release the newer python3.6 with this remedy, because of near the end of life of 3.6.

Workaround1: Use GCC version 10. The GCC-10 seems not to have this problem.
 command: env CC=gcc-10 pyenv install 3.6.15

Workaround2: Use -O2 level with GCC-11. The "-O2" seems to skip the vectorize optimization so that GCC doesn't apply "movaps" at all. As a result, it can avoid this problem.
 command: env CFLAGS=-O2 pyenv install 3.6.15
---
Takahide Nojima
msg405638 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2021-11-03 18:24
As you note, Python 3.6 is almost at end-of-life, in fewer than two months from now. And, in any case, it is in the security-fix-only phase of its life cycle so changes just to support OS platform or build tool updates are out-of-scope in general, not to mention anything that might cause an ABI or API change. Thanks for the suggestion and documenting workarounds, though!
History
Date User Action Args
2022-04-11 14:59:52adminsetgithub: 89863
2021-11-03 18:24:28ned.deilysetstatus: open -> closed

nosy: + ned.deily
messages: + msg405638

resolution: wont fix
stage: resolved
2021-11-03 08:54:55Nojima Takahidecreate