-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
llama.cpp assertion fails: "non-causal attention requires n_ubatch >= n_tokens" #2375
Comments
I can replicate this problem (as I was testing for someone else's different localdocs crashing problem). Exception Type: EXC_CRASH (SIGABRT) Some stack trace context - let me know if you want the complete one. |
Can I try something to help? I don't know why the crash report windows doesn't open anymore... |
(wazoox) sorry I was directing my comment to the devs. However, I am sure anyway you can help would be appreciated. Right before it crashed it logged this to file: Not sure the relationship of he above but may be helpful. |
If this adds any context, also on macOS. Monterey 12.6.9 M1 Max. Running on CPU. When I use localdocs. If I use a prompt that deliberately would not have similarity to any of the content in the PDFs in the localdocs all works as expected. If I use a prompt that matches content in the localdocs GPT4All crashes. Crash Thread 8 ... |
UPDATE: I installed version 2.7.3 macOS and repeated the steps: same model Nous-Hermes-2-Mistral-7B-DPO.Q4_0.gguf, same localdocs directory, same SBERT model for localdocs. And GPT4All does NOT crash. Seems to be working as expected. This does appear to be a v 2.8.0 issue. (although I have not yet tried with v 2.7.4) |
I found an issue with embedInternal that could be related, but since I haven't seen this particular crash I'm not sure that it's the same. @chrisbarrera Could you run GPT4All from a terminal ( Here are the steps I followed to try and replicate the issue on macOS Sonoma 14.4.1:
After this I also tried:
For me, GPT4All does not crash. What are you doing differently? |
The problem went away when I removed localdocs* db under 2.8.0 and recreated the localdocs dbs, but I could replicate it by removing it again and rerunning under 2.7.5 to recreate the DB's, then switching back to 2.8.0. Here is the output generated as I recreate the crash by attempting to add a new collection to localdocs under 2.8.0: |
I can reproduce the assertion failure from the python bindings:
Looks like we are not correctly setting n_ubatch after the llama.cpp update from the CUDA PR. |
the bug:
Going to settings, Local Docs, pointing to a folder containing a few PDFs; when clicking "Add" GPT4All crashes. It then crashes at startup until I delete the localdocs_v1.db file.
"Local Docs" used to work on this machine with GPT4All 2.7.3.
GPT4All works fine if I reset all settings but don't set up any Local Docs.
If I set up an empty folder as a Local docs, it works; however as soon as I drop a PDF into this folder, GPT4All crashes.
After restart, GPT4All crashes once if there's any new PDF in the Local Docs, then run the second time. However if I ask specific questions related to the Local Docs, it doesn't seem to use them.
configuration:
Running GPT4All 2.8.0 on MacOS Monterey 12.7.5 (Mac Pro Intel 32 GB RAM).
installed local models
Meta-Llama-3-8B-Instruct.Q4_0.gguf
Nous-Hermes-2-Mistral-7B-DPO.Q4_0.gguf
all-MiniLM-L6-v2-f16.gguf
all-MiniLM-L6-v2.gguf2.f16.gguf
mistral-7b-instruct-v0.1.Q4_0.gguf
mistral-7b-openorca.Q4_0.gguf
mistral-7b-openorca.gguf2.Q4_0.gguf
debugging
Unfortunately the first few crashes opened a debugging window with traces, but it doesn't happen anymore for some reason.
The text was updated successfully, but these errors were encountered: