2

Background

Hi, my main goal is to create a virtualenv for a number of projects that use older versions of python, which are separate from the system version (3.10.x). I'm using PopOS 22.04, with all updates.

I can't even use pip because of this error. I also read around, but all of the solutions I read either output a log file, or some other indication of what went wrong. Whereas I have nothing but Segmentation fault (core dumped) in the terminal.

I tried doing the above with pyenv before this, but it had so many bugs that I got sick of it after 20+ hours... This is also my first time installing anything from source, but I did read the README.

Exact steps followed

  1. I downloaded and installed python 3.5.2 from source from https://www.python.org/downloads/release/python-352/
  2. Extract folder in ~/Downloads/
  3. cd Python-3.5.2/
  4. ./configure
  5. make
  6. sudo make altinstall
  7. cd ../../Desktop/
  8. whereis python3.5 # outputs /usr/local/bin/python3.5
  9. virtualenv my_venv -p /usr/local/bin/python3.5
  10. source my_venv/bin/activate # activates (my_venv)
  11. python # opens python 3.5.2 shell, not the system's 3.10.x
  12. quit()
  13. pip -h
  14. Response is merely: Segmentation fault (core dumped)... That's it. no indication of a log file anywhere to trace it back, nothing. Trying to install anything gives the same response. I even ran sudo apt install python3-pip, and get the following answer for that:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
python3-pip is already the newest version (22.0.2+dfsg-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I also tried...

I also tried the above with python3.7.5, but this time I ran make test before doing the install.

It's currently showing this in the terminal: running: test_faulthandler (1 hour 6 min).

And I noticed some people say it can go for a couple hours, but doing this can help find some issues, and patch them or whatever. I'll wait it out to see what happens, but...

Does anyone have any experience in this / know what to do???

Thanks!

CyberHavenProgramming
  • 1,136
  • 7
  • 19

1 Answers1

1

I had a similar issue trying to install packages via pip using Python 3.6.15 compiled from source on Arch Linux. For example, the following steps would result in Segmentation fault (core dumped) being printed with no further detail, regardless of the package to be installed:

$ <path-to-python-install>/bin/python3.6 -m venv test-venv
$ source test-venv/bin/activate
(test-venv) $ pip install <some-package>

Segmentation fault (core dumped)

Solution

The solution involves applying this patch, originally posted by Benjamin Peterson. The patch modifies the object allocation code to use 16 byte alignment instead of the 8 bytes assigned by pymalloc that causes the segmentation faults. I believe this issue was fixed in Python versions >=3.7.

Applying the Patch & Compiling from Source

Enter the following commands sequentially into your terminal to download the source code, extract it, apply the patch, configure the build, build Python and clean up:

cd ~
mkdir py36
mkdir py36/tempfiles
cd py36/tempfiles
curl https://www.python.org/ftp/python/3.6.15/Python-3.6.15.tar.xz --output Python-3.6.15.tar.xz
tar -xJvf Python-3.6.15.tar.xz
cd Python-3.6.15
vim alignment.patch  # Use your preferred text editor
# Paste the contents of the patch, save and quit
patch -p0 < alignment.patch
cd ..
Python-3.6.15/configure --prefix=/home/<username>/py36 --enable-optimizations --with-lto
make
make install
cd ..
rm -rf tempfiles

A working Python 3.6.15 build with the patch applied will now be available in ~/py36. Test that the pip package manager works as expected:

$ ~/py36/bin/python3.6 -m venv ~/test-venv
$ source ~/test-venv/bin/activate
(test-venv) $ pip install <some-package>

You may need to upgrade pip and setuptools if you experience some issues installing some packages.

pip install --upgrade pip
pip install --upgrade setuptools

Pseudo-Solution

Another solution that only worked temporarily was to comment out the following line in the pip file (as mentioned in the same GitHub issue where the patch was suggested, which cites this French article by Johackim):

sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])

To find the location of the pip file that is used by the virtual environment, run the which pip command inside the virtual environment, e.g.:

(test-venv) $ which pip

However, this only worked temporarily for me, whereas the patch has been reliable thus far.

Kyle F Hartzenberg
  • 2,567
  • 3
  • 6
  • 24