Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-24 12:05:51 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #43] Segmentation fault (core dumped) under Ubuntu 22.04 #27

New Issue
Closed
opened 2026-02-22 18:17:31 -05:00 by yindo · 7 comments
yindo commented 2026-02-22 18:17:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @danglingptr0x0 on GitHub (Jun 13, 2023).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/43

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). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/43 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.
yindo added the question label 2026-02-22 18:17:31 -05:00
yindo closed this issue 2026-02-22 18:17:31 -05:00
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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.
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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.
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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!
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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
yindo commented 2026-02-22 18:17:32 -05:00
Author
Owner
Copy Link
Copy Source

@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
yindo changed title from Segmentation fault (core dumped) under Ubuntu 22.04 to [GH-ISSUE #43] Segmentation fault (core dumped) under Ubuntu 22.04 2026-06-05 14:33:04 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#27
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?