starred/anything-llm

Fork 0

mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-03-02 22:57:05 -05:00

Segmentation fault (core dumped) under Ubuntu 22.04 #26

New issue

Closed

opened 2026-02-28 04:20:28 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 04:20:28 -05:00

Owner

Originally created by @danglingptr0x0 on GitHub (Jun 13, 2023).

I am experiencing a segfault when submitting a second request in a new workspace with 117 embedded docs (~169k tokens).

..[$] <()> yarn dev:server
yarn run v1.22.19
$ cd server && yarn dev
$ NODE_ENV=development nodemon --ignore documents --ignore vector-cache --trace-warnings index.js
[nodemon] 2.0.22
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node --trace-warnings index.js`
Example app listening on port 3001
SELECT * FROM workspaces WHERE slug = 'obsidian'
SELECT * FROM workspaces  
SELECT * FROM workspace_documents WHERE workspaceId = 1 
SELECT * FROM workspaces WHERE slug = 'obsidian'
SELECT * FROM workspace_documents WHERE workspaceId = 1 
SELECT * FROM workspace_chats WHERE workspaceId = 1 AND include = true  ORDER BY id ASC
SELECT * FROM workspaces WHERE slug = 'obsidian'
SELECT * FROM workspace_documents WHERE workspaceId = 1 
SELECT * FROM workspaces WHERE slug = 'obsidian'
SELECT * FROM workspace_documents WHERE workspaceId = 1 
Segmentation fault (core dumped)
[nodemon] app crashed - waiting for file changes before starting...

browser console:

TypeError: NetworkError when attempting to fetch resource. [workspace.js:51:17](http://localhost:3002/src/models/workspace.js)
    chatResult workspace.js:51
    (Async: promise callback)
    sendChat workspace.js:50
    fetchReply index.jsx:49
    ChatContainer index.jsx:66
    React 15
    handleSubmit index.jsx:32
    captureEnter index.jsx:22
    React 23
    <anonymous> main.jsx:9

I noticed that "resaving" a workspace fixes the issue, but only until a second request is sent. Sending one works, but the second one causes the segfault. At that point, restarting the server first and the frontend second and then resaving the workspace in the frontend, once again, fixes the issue temporarily, in the same manner. The core that was dumped is 337MB and appears to contain sensitive info, so not sharing now.

Originally created by @danglingptr0x0 on GitHub (Jun 13, 2023). I am experiencing a segfault when submitting a second request in a new workspace with 117 embedded docs (~169k tokens). ``` ..[$] <()> yarn dev:server yarn run v1.22.19 $ cd server && yarn dev $ NODE_ENV=development nodemon --ignore documents --ignore vector-cache --trace-warnings index.js [nodemon] 2.0.22 [nodemon] to restart at any time, enter `rs` [nodemon] watching path(s): *.* [nodemon] watching extensions: js,mjs,json [nodemon] starting `node --trace-warnings index.js` Example app listening on port 3001 SELECT * FROM workspaces WHERE slug = 'obsidian' SELECT * FROM workspaces SELECT * FROM workspace_documents WHERE workspaceId = 1 SELECT * FROM workspaces WHERE slug = 'obsidian' SELECT * FROM workspace_documents WHERE workspaceId = 1 SELECT * FROM workspace_chats WHERE workspaceId = 1 AND include = true ORDER BY id ASC SELECT * FROM workspaces WHERE slug = 'obsidian' SELECT * FROM workspace_documents WHERE workspaceId = 1 SELECT * FROM workspaces WHERE slug = 'obsidian' SELECT * FROM workspace_documents WHERE workspaceId = 1 Segmentation fault (core dumped) [nodemon] app crashed - waiting for file changes before starting... ``` browser console: ``` TypeError: NetworkError when attempting to fetch resource. [workspace.js:51:17](http://localhost:3002/src/models/workspace.js) chatResult workspace.js:51 (Async: promise callback) sendChat workspace.js:50 fetchReply index.jsx:49 ChatContainer index.jsx:66 React 15 handleSubmit index.jsx:32 captureEnter index.jsx:22 React 23 <anonymous> main.jsx:9 ``` I noticed that "resaving" a workspace fixes the issue, but only until a second request is sent. Sending one works, but the second one causes the segfault. At that point, restarting the server first and the frontend second and then resaving the workspace in the frontend, once again, fixes the issue temporarily, in the same manner. The core that was dumped is 337MB and appears to contain sensitive info, so not sharing now.

deekerman

2026-02-28 04:20:28 -05:00

closed this issue
added the
question
label

deekerman commented

2026-02-28 04:20:44 -05:00

Author

Owner

@danglingptr0x0 commented on GitHub (Jun 13, 2023):

UPDATE: actually, the "resaving" approach doesn't work anymore. It now segfaults even if I open the workspace settings modal and save again with no changes, which worked previously. As such, I think that the fact that it worked was likely a coincidence.

@danglingptr0x0 commented on GitHub (Jun 13, 2023): UPDATE: actually, the "resaving" approach doesn't work anymore. It now segfaults even if I open the workspace settings modal and save again with no changes, which worked previously. As such, I think that the fact that it worked was likely a coincidence.

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@danglingptr0x0 commented on GitHub (Jun 13, 2023):

UPDATE: creating a new workspace and embedding the files again causes the segfault on the first request already. can't determine why, but I believe that it could be due to my high doc/token count. no evidence to support that, though

@danglingptr0x0 commented on GitHub (Jun 13, 2023): UPDATE: creating a new workspace and embedding the files again causes the segfault on the first request already. can't determine why, but I believe that it could be due to my high doc/token count. no evidence to support that, though

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@danglingptr0x0 commented on GitHub (Jun 13, 2023):

The issue occurs even when embedding low doc count in a workspace. In my case, I got a segfault when I created a new workspace and embedded only a small subset of my dataset (16 docs). I have a feeling that the issue could lie somewhere in the vector db, so will try using either chromadb or pinecone to verify that

@danglingptr0x0 commented on GitHub (Jun 13, 2023): The issue occurs even when embedding low doc count in a workspace. In my case, I got a segfault when I created a new workspace and embedded only a small subset of my dataset (16 docs). I have a feeling that the issue could lie somewhere in the vector db, so will try using either chromadb or pinecone to verify that

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@timothycarambat commented on GitHub (Jun 13, 2023):

Are you using lance as your vectorDB? This very much sounds like a lance issue.

@timothycarambat commented on GitHub (Jun 13, 2023): Are you using `lance` as your vectorDB? This very much sounds like a lance issue.

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@timothycarambat commented on GitHub (Jun 13, 2023):

Also pull the latest changes and run this via docker since that is now supported. Lance worked inside of docker without issue!

@timothycarambat commented on GitHub (Jun 13, 2023): Also pull the latest changes and run this via `docker` since that is now supported. Lance worked inside of docker without issue!

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@danglingptr0x0 commented on GitHub (Jun 13, 2023):

Are you using lance as your vectorDB? This very much sounds like a lance issue.

yup.

Also pull the latest changes and run this via docker since that is now supported. Lance worked inside of docker without issue!

I did, and I can't get it up and running. I have no idea why. Tried with chromadb first, though, when I pulled the latest revision today (the one adding docker supported, as you mentioned), but chromadb using docker-compose just didn't work correctly. The dev:server wasn't able to connect to it on the default port 8000, even though I followed the setup instructions. Maybe I missed something since the official chromadb docs are very vague on the setup docker-compose setup.

I ended up using pinecone, which actually doesn't work either. I must be doing something wrong. Gonna delete and clone the repo again and run the docker setup from scratch.

Thanks

@danglingptr0x0 commented on GitHub (Jun 13, 2023): > Are you using `lance` as your vectorDB? This very much sounds like a lance issue. yup. > Also pull the latest changes and run this via `docker` since that is now supported. Lance worked inside of docker without issue! I did, and I can't get it up and running. I have no idea why. Tried with chromadb first, though, when I pulled the latest revision today (the one adding docker supported, as you mentioned), but chromadb using docker-compose just didn't work correctly. The dev:server wasn't able to connect to it on the default port 8000, even though I followed the setup instructions. Maybe I missed something since the official chromadb docs are very vague on the setup docker-compose setup. I ended up using pinecone, which actually doesn't work either. I must be doing something wrong. Gonna delete and clone the repo again and run the docker setup from scratch. Thanks

deekerman commented

2026-02-28 04:20:46 -05:00

Author

Owner

@danglingptr0x0 commented on GitHub (Jun 14, 2023):

Works with pinecone under macOS, which currently solves the issue for me

@danglingptr0x0 commented on GitHub (Jun 14, 2023): Works with pinecone under macOS, which currently solves the issue for me

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anything-llm#26

No description provided.

Rows
Columns