FAISS search fails with vague error: "Illegal instruction" or kernel crash - python-3.x

Currently trying to run a basic similarity search via FAISS with reproducible code from that link. However, every time I run the code in the following venues, I have these problems:
Jupyter notebook - kernel crashes
VS Code - receive "Illegal Instruction" message in the terminal with no further documentation
I've got similar code working in Kaggle, so I suppose the problem is with my particular setup.
Based on the print statements, it appears that the error occurs during the call of the .search method. Because of how vague this error is, I've not been able to find much information on the problem. It seems that some people mentioned older processors may have a problem (AVX/AVX2 flags being the culprit?), though admittedly I didn't quite understand the connections.
Problem: Can I get some help understanding this error, and if possible, a potential solution?
Current setup:
WSL2
VSCODE (v. 1.49.0)
Jupyter-client (v. 6.1.7)
Jupyter-core (v. 4.6.3)
FAISS-cpu (v. 1.6.3)
Numpy (v. 1.19.2)
Older machine (AMD FX-8350 with 16GB RAM)

For anyone that runs across this error, the problem (in my case) was that my CPU was old enough that it doesn't support AVX2. To determine this, I used this SO post.
Once I ran the code in Colab or on a newer machine, all was well.

Related

TypeError: As of 3.10, the *loop* parameter was removed from Lock() since it is no longer necessary

How do I solve this?
TypeError: As of 3.10, the *loop* parameter was removed from Lock() since it is no longer necessary
I'm trying to use Binance socket manager, and I'm getting this error.
Should just be a case of upgrading your websockets version from 9.1 to 10.x
pip install --upgrade websockets
I've had the same issue. My bot ran fine on MacOS, but it popped up when I installed Fedora on the Apple instead. Never resolved it before moving on to other OS's, but I don't know if it would have happened on Ubuntu or Zorin, because a PIP problem stopped me long before then.
As for my primary, an MSI gaming laptop running Windows 11, I never had the issue on the command line python, IDLE, PyCharm, Visual Studio, nor Visual Studio Code, UNTIL this morning when my laptop overheated and shutdown. When I booted up again, the system no longer recognized the modules I had been using (pandas, pytz, python-binance) and they had to be installed again (from an elevated command line, which seemed odd). Then when running the program from VS, there comes the error again. Command prompt returns the same error, however, IDLE runs the program without issue. I'm not knowledgeable enough to say how to directly fix the bug, or even why it's happening, but it seems that there may be methods of skirting it. The error reads 'As of 3.10...' so if you cannot find an application that can run it, you might try rolling it back to 3.9. Sorry I can't be of any real aid, here. Hope you find your answers. I'll keep looking, too.
I've come up with several solutions.
I created my own ticker:
play = client.get_symbol_ticker(symbol='BTCUSDT)
def start_ticker():
global play
while True:
play = client.get_symbol_ticker(symbol='BTCUSDT')
print(play['Price'])
time.sleep(1)
bsm = ThreadedWebsocketManager()
bsm.start()
start_ticker()
Now, this is just a sort of preliminary example. I've tied it into my actual trading loop and removed the print function, but store and process the data second by second. I run multiple tokens simultaneously and set the sleep at the end of the entire loop, after the condition evaluations have been processed. You can tweak the rest time after testing the duration of your loop, but overall it's hasn't ever shown to be critical for it to be off by fragments of a second. One caveat is that it only delivers the flat price, but you can check the documentation for additional queries you can pull from: Python Binance 0.2.0 Websockets Documentation
Install Python 3.9:
This is easiest on Windows, as no system processes rely on it. If you install it parallel to your current version, you'll have to take extra steps to address it rather than the later version, such as with PATH edits or virtual environments. An easy tool for this is Anaconda, which can create the virtual environment with little fuss.
I run my trader on a PC running Fedora, which has proven to be more reliable with server connections (unfortunately, Windows 11 can't keep proper time without a looping PowerShell script that manually resyncs, and I get Windows semaphore errors even with the time issue fixed). However, Fedora relies on up-to-date Python for some system functions, so you have to install the pre-3.10 version beside it an create a symbolic link and a virtual environment to run it.
Modify the python-binance module to use a different Loop function, which I believe can be done with PyCharm or Anacondas, but from what I read it's not the best of ideas and I don't see a need for it at the moment. Also, I would probably just break it.
TypeError: As of 3.10, the *loop* parameter was removed from Queue() since it is no longer necessary
I was getting this error when i try to use proxybroker package.
I just downgrade python version to 3.6.8 and now error is gone.
Maybe your error to occurred by python version.
maybe helps
Make sure u installed asyncio and imported that. I had the same problem.

Issue Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA

I met this issue when I running my python file in linux.
I searched some answers in google like use the code below:
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '2'
The system can be running but without ant out information. Actually I found the 2 measn ignore all information while 1 means give all information like error or normal output.
because I need to use GPU so my original code is:
os.environ["CUDA_VISIBLE_DEVICES"]="0"
But if I keep the code my output would be an error information like the title.
How can I do? and of course I need use the GPU and the codes can be running in colab which indicated that my code has no problem.
some guys even said uninstall tensorboard...that must a wrong way.
Or should I download tensorflow gpu not tensorflow in m,y virtual enviroment? when I USE THE tensorflow gpu version, the error is core dumped.
If when forcing the os.environ["CUDA_VISIBLE_DEVICES"]="0" doesn't work, then this means that your tensorflow gpu installation did not succeed. You must ensure you have the right combination of TensorFlow + CUDA + CUDNN. That is why you get the error, because due to improper versions/installation TF falls back on CPU.

Code working on windows but launch failures on Linux

First and foremost: I am completely unable to create a MCVE, as I can only reproduce this when running a full code, any attempt to measure or replicate the error in a simpler environment makes it disappear. TDLR I suspect its not a code problem, but a configuration problem.
I have a piece of code for some mathematics on kernels in CUDA. I have a windows machine Win10 x64, GTX 1050, CUDA 9.2 and a Ubuntu 17.04, 2xGTX 1080 Ti, CUDA 9.1.
My code runs good on the windows machine. It is long (~700ms per kernel call for big samples) so I needed to increase the TDR value in windows. The code also (for now) forces it to run in 1 GPU, the first one that is selected with cudaSetDevice(0).
When I copy the same input data and code to the linux machine (I am using git, it is the same code), I get either
an illegal memory access was encountered
or
unspecified launch failure
in my error checking after the GPU call.
If I change the kernel to instead do the math, to just write a number in the output, the kernel executes properly. Other CUDA code (different functions that I have) works fine too. All this leads me to think that there is a problem outside the code, not with the code itself, nor with the general configuration of the drivers/environment variables.
I read that the xorg.conf can have an effect on the timeout of the kernels. I generated a xorg.conf (I had none) and remove the devices from there, as suggested here. I am connecting to the server remotely, and have no monitor plugged in. This changes nothing in the behavior, my kernels still error.
My question is: what else should I look? What linux specific configuration should I have a look at to pinpoint the cause of the kernel halts?
The error ended up being indeed illegal memory access.
These were caused by the fact that sizeof(unsigned long) is machine specific, and my linux machine returns 8 while my windows machine returns 4. As this code is called from MATLAB, and MATLAB (like some other high level languages such as python) defines the sizes of variables in bits (such as uint32(1)) there was a mismatch in the linux machine when doing memcpys. Turns out that this happened in a variable that is a index, so the kernels were reading garbage (due to the bad memcpy), but then triying to access another array at that location, creating an illegal memory error.
Too specific? yeah.

What is xsession-errors?

So I was looking into why a program was getting rid of my background, and the author of the program said to post .xsession-errors and many people did. Then my next question was: What is .xsession-errors? A google search reveals many results but nothing explaining what it is.
What I know so far:
It's some kind of error log. I can't figure out what it's related too (ubuntu itself? programs?)
I have one and it seems like all Ubuntu systems have it, though I cannot verify.
Linux graphical interfaces (such as GNOME) provide a way to run applications by clicking on icons instead of running them manually on the command-line. However, by doing so, output from the command-line is lost - especially the error output (STDERR).
To deal with this, some display managers (such as GDM) pipe the error output to ~/.xsession-errors, which can then be used for debugging purposes. Note that since all applications launched this way dump to the same log, it can get quite large and difficult to find specific messages.
Update: Per the documentation:
The ~/.xsession-errors X session log file has been deprecated and is
no longer used.
It has been replaced by the systemd journal (journalctl command).
It's the error log produced by your X windows system (which the Ubuntu GUI is built on top of).
Basically it's quite a low level error log for X11.

Error OpenCV with CUDA using TBB for multiple GPUs

My OpenCV CUDA program runs fine using a single NVidia 580GTX, but when using another, it gives the following error:
OpenCV Error: Gpu API call (invalid device ordinal) in mallocPitch
I know I need TBB to assign a GPU its job, but even though I installed OpenCV with TBB support (followed the willowgarage website), it says TBB support is required (CMake key 'WITH_TBB' must be true). Any help would really be appreciated since I need this to complete my computer science Master's project.
Thanks!
Ok its solved. turns out it was build 7232 that was the problem, since it works with the latest opencv build(7292) with no problems. Thanks all for the support

Resources