Repository navigation
[Issue]: [Bug][Linux] flm serve crash: C++ assertion failure '!this->empty()' in std::vector<logits_t>::back() #725
Description
Problem Description
Crashed Thread Stack Trace:
1 Thread 1 (Thread 0x7f92069fd6c0 (LWP 3577901)):
2 #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at
pthread_kill.c:44
3 #1 0x00007f934609a243 in __pthread_kill_internal (threadid=, signo=6) at pthread_kill.c:89
4 #2 0x00007f934603e5d0 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
5 #3 0x00007f9346025685 in __GI_abort () at abort.c:77
6 #4 0x00007f934649d5bd in std::__glibcxx_assert_fail (file=, line=, function=, condition=) at ../../../../../gcc/libstdc++-v3/src/c++11/assert_fail.cc:41
7 #5 0x0000562ef5ae03ae in ?? ()
8 #6 0x0000562ef5d3bd67 in ?? ()
Root Cause & Technical Analysis (GDB Core Extraction):
By examining the assembly and register values inside flm right before the abort call (std::__glibcxx_assert_fail), we
extracted the RIP-relative string parameters:
- Assertion File: /usr/include/c++/16/bits/stl_vector.h (Line 1360)
- Assertion Function:
1 constexpr std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::back() [with _Tp = logits_t; _Alloc =
std::allocator<logits_t>; reference = logits_t&]
- Failed Condition: !this->empty()
The program counter at 0x0000562ef5ae03ae is preceded by the assertion instruction block:
1 0x0000562ef5ae038e: lea 0x6a5b31(%rip),%rcx # 0x562ef6185ec6 -> "!this->empty()"
2 0x0000562ef5ae0395: lea 0x6beb34(%rip),%rdx # 0x562ef619eed0 -> "std::vector<logits_t>::back()"
3 0x0000562ef5ae039c: mov $0x550,%esi # 0x550 = Line 1360
4 0x0000562ef5ae03a1: lea 0x6b3708(%rip),%rdi # 0x562ef6193ab0 -> "/usr/include/c++/16/bits/stl_vector.h"
5 0x0000562ef5ae03a8: call *0x94e75a(%rip) # Calls __glibcxx_assert_fail
This proves that flm called logits.back() when logits had a size of 0.
Environment & Package Details:
- OS: Arch Linux (Kernel 6.x / AMD Ryzen AI NPU configuration)
- Compiler/Libc: GCC 16 / glibc 2.40 / libstdc++ 16.x (compiled with standard -D_GLIBCXX_ASSERTIONS)
- FastFlowLM Version: fastflowlm 1.0.4-1
- Model in use: qwen3-it:4b (Qwen3-4B-Instruct-2507-NPU2)
- Hardware: AMD Ryzen NPU (managed via /usr/lib/libxrt_driver_xdna.so.2)
Proposed Fix:
Add a safety check to ensure that the logits vector is populated before fetching the trailing element:
1 if (!logits.empty()) {
2 auto last_logit = logits.back();
3 // ... process logit
4 } else {
5 // Handle empty logits list gracefully or return error code
6 }
Filed by Gemini via Gemini CLI.
Operating System
Omarchy 4.0.3-1
CPU
AMD Ryzen AI 5 340 w/ Radeon 840M
GPU
iGPU: AMD Radeon 840M (Krackan, 1002:1114) NPU: NPU Krackan 1 [0000:c2:00.1] (used by FastFlowLM)
ROCm Version
ROCm not installed. FastFlowLM uses XRT 2.21.75 + NPU firmware 1.1.2.64 (not the ROCm GPU stack).
Installation Method
Other (describe in Additional Information)
Installed ROCm Packages / Versions
# Installation: Arch/Omarchy pacman (not pip) fastflowlm 1.0.4-1 xrt 1:2.21.75-14 xrt-plugin-amdxdna 1:2.21.75-2 lemonade-server 11.9.0-2 # Runtime FLM v1.0.4 XRT 2.21.75 amdxdna (kernel) 7.2.3-arch1-3 NPU Firmware 1.1.2.64 kernel 7.2.3-arch1-3 flm validate ready=true, all_fw_ok=true, device=/dev/accel/accel0, drm_version=0.10 # ROCm not installed (no rocminfo, no /opt/rocm, no pip packages)
ROCm Component
No response
Steps to Reproduce
No response
(Optional for Linux users) Output of rocminfo --support
rocminfo --support output
Paste output here
Additional Information
No response
Activity
ripiox commentedon Sep 23, 2026
+1 confirming — same assertion, same code path, seen twice (two independent
flm serveruns) on Linux under load.Environment
extrapackage,fastflowlm 1.0.6-1)7.2.5-4-omarchy, in-treeamdxdna(reported as 0.10 byflm validate)/dev/accel/accel0with 8 columns, PCI1022:17f0— Ryzen AI 5 PRO 340 (Krackan Point), Lenovo subsystemqwen3:4bagainstflm serve llama3.2:1b --pmode balanced; FLM hot-loadsQwen3-4B-NPU2, prefill chunk 1/1 (18 tokens), aborts.Key detail: the model file was truncated, and FLM's integrity tooling said it was fine
~/.config/flm/models/Qwen3-4B-NPU2/model.q4nxwas 1,407,709,184 bytes (~45% of the expected ~3.1 GB) because the download had been interrupted. Even so:flm listmarkedqwen3:4b ✅(installed)All files verified successfully.So the download-verification path does not detect a truncated
.q4nx(related: #461 was closed as fixed, but the crash family + the ❎ "verified successfully" message on a partial file suggest the fix was not complete).flm checkdid eventually flag the file ("Use flm pull ... to re-download corrupted files") after the fact.After a clean full re-download, this model; another model (llama3.2:1b) serves chat fine on the same box.
Suggestion: 1) detect truncated/partial
.q4nxduring download resume (note expected size before streaming) and, 2) fail the serving request with a clean error instead of aborting the whole serve process on an internal assert.