I’ve been using streamlit for almost 1 year. However - we recently went through a period of working on other applications in our project which were part of the same virtual environment.
This meant for me needing to upgrade my python version to 3.7.9. I use deadsnake for this on Ubunutu 18.04
Now here comes the nasty part. I now see an error message coming from Streamlit which simply outputs: “Illegal instruction”. Has anyone seen this before. It even happens on the simple ‘hello’ application. e.g.
(streamlit_3.8) nherriot@kieran:~/virtualenv/streamlit_3.8/project/streamlit$ python --version
(streamlit_3.8) nherriot@kieran:~/virtualenv/streamlit_3.8/project/streamlit$ python
Python 3.8.6 (default, Oct 6 2020, 03:22:36)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
(streamlit_3.8) nherriot@kieran:~/virtualenv/streamlit_3.8/project/streamlit$ streamlit hello
I’m guessing that it’s calling up some binary which is trying to execute something for the wrong architecture (machine architecture). The machine is an AMD Phenom™ II X6 1090T Processor × 5
Any help on how to get more debug on this would be great!
more information on this error:
If I move streamlit back to version 0.52.0 it goes away.
So this has been introduced with the new releases. Also what is interesting is that it does not happen on my Intel laptop running Linux mint.
(streamlit) nherriot@kieran:~/virtualenv/streamlit/project/streamlit$ streamlit --version
Streamlit, version 0.52.0
(streamlit) nherriot@kieran:~/virtualenv/streamlit/project/streamlit$ streamlit hello
You can now view your Streamlit app in your browser.
Local URL: http://localhost:8501
Network URL: http://192.168.8.201:8501
Can you confirm that you’re using a 64-bit version of Python?
Having the breakpoint at <0.63 is an interesting place, as 0.63 is where we released the custom components framework. With that, we added Apache Arrow as a dependency. So I’m wondering if there is an issue with that somehow.
First of all, thank you very much for bringing this up both on GitHub and here, and sorry we didn’t get back sooner! I hope that we figure out a solution here. We have been unable to repro on our systems (both macOS and Ubuntu), so this will be a little tricky to identify the solution.
“Illegal Instruction” errors occur when you try to run a program that was compiled with some processor-specific optimizations, and is then running on a processor that fails to meet those requirements. This leads me to think that something we introduced either wasn’t compiled correctly for your processor or something strange happened on your system when combined with our changes caused issues.
Here are a few ideas to try:
(From a colleague) The AMD Phenom processor is not a unique processor, just an AMD64-compatible CPU, so it should be using the same Python binaries as all AMD and Intel CPUs from the past 15 or so years.That said, it may be worth a try having them build their own Python by using pyenv , since it looks like they’re installing theirs from a PPA (which I don’t trust 100%…). Also the PPA is for Ubuntu and their system is Elementary —which is based on Ubuntu, but may have some different libraries, which could be causing issues.
# Install pyenv
$ curl -L https://github.com/pyenv/pyenv-installer/raw/master/bin/pyenv-installer | bash# Install Python 3.7
$ ~/.pyenv/bin/pyenv install 3.7.0# Then point to the newly installed Python when creating the virtual env
$ mkvirtualenv streamlit --python=~/.pyenv/versions/3.7.0/bin/python
From then on, all pip packages are actually compiled on the users’ machine so they should all work fine.
As @randyzwitch pointed out, the marked change between 0.62 and 0.63 is the introduction of a new package called pyarrow. It’s possible (but perhaps a little shocking) that it caused the problem. We don’t import arrow when you run streamlit --version, so that shouldn’t crash. But in any case, you can try to install pyarrow from Conda and see if that fixes it. It’s a long shot, but worth a try.
All these ideas are educated guesses that I hope either yield fruitful results or at least more information to solve the problem. Let us know what you end up figuring out.
Note: I’m going to post this comment on the GitHub issue, and will continue responding on there. Given it’s public and perhaps more “Googleable” I think it will be useful for more users who hit similar issues there.