Segmentation fault during Force Rebuild of embeddings with large note collection

Description: I am running self-hosted Blinko in Docker with a local Ollama instance. I have approximately 8,210 notes imported from Markdown. Blinko repeatedly crashes with Segmentation fault (core dumped) while running Force Rebuild for embeddings. The crash does not occur at the same note each time. Examples: Run 1: stopped around 719 notes Run 2: stopped around 798 notes Run 3: stopped around 370 notes Run 4: stopped around 672 notes After the segmentation fault, Docker automatically restarts Blinko and Blinko starts normally again. Environment Blinko: blinkospace/blinko:latest (updated to latest image before retesting) Docker storage driver: overlay2 Backing filesystem: btrfs PostgreSQL 14 Ollama: ollama/ollama:latest, separate Docker container on the same Docker network Ollama Base URL in Blinko: http://ollama_ollama-1:11434/api Main chat model: qwen3:4b-instruct Embedding model originally: nomic-embed-text Embedding model subsequently tested: all-minilm Approximately 8,210 notes Host has approximately 64 GB RAM Direct Ollama test all-minilm works normally when called directly through Ollama /api/embed. A simple embedding request completes in approximately 0.5 seconds. Memory testing I monitored the containers with docker stats during Force Rebuild. Before rebuild: blinko ~339 MiB During rebuild: blinko ~755 MiB Ollama remained around ~207 MiB and PostgreSQL around ~120 MiB. The Blinko process/container subsequently restarted and memory returned to ~258 MiB. Docker reports: Restarts=10 OOMKilled=false Therefore the crashes do not appear to be caused by the host OOM killer or exhaustion of system RAM. Example log immediately before crash processing note 797, progress: 793/8210 processing note 798, progress: 794/8210 processing note 799, progress: 795/8210 processing note 800, progress: 796/8210 processing note 801, progress: 797/8210 processing note 802, progress: 798/8210 Segmentation fault (core dumped) Blinko then restarts and initializes normally. Because the failure occurs at substantially different positions on different rebuild attempts, it does not appear to be caused by one specific note. Additional observation dmesg repeatedly contains: overlayfs: maximum fs stacking depth exceeded Docker reports: Storage Driver: overlay2 Backing Filesystem: btrfs I don't know whether the OverlayFS messages are related to the segmentation fault. Please let me know if there are additional logs, core-dump information, or debugging commands I can provide.