Repository navigation
Android API inference crash: SIGABRT in MNN::DeferBufferAllocator::apply() / MNN::Session::resize() #4811
Description
Activity
Thanks for the detailed report. The abort message (
Pointer tag ... was truncatedinfree←DeferBufferAllocator::apply) means the 8-byte slot whereMNNMemoryAllocAlignstores the original malloc pointer was corrupted before the arena was freed and re-grown on that resize — the free insideapply()is just where the corruption surfaced, not its origin.We traced the lifetime of the CPU raster cache and found a real defect matching this crash chain (3rd request → session resize → arena realloc):
CPUResizeCacheentries survived across resizes, butCPURasterconsumes a cache hit without re-acquiring the buffer. AfterDeferBufferAllocator::reset()freed the old arena andapply()reallocated a larger one, a stale cache hit returned a tensor still bound to the freed arena. Any access through it is a use-after-free over the arena's neighbor allocations — exactly the kind of corruption that lands in the stored-origin slot adjacent to an aligned buffer.
Fix implemented (not yet merged): cache entries are now scoped to a single resize —
release()empties the lookup map while nulling the mem of cached tensors (the tensor objects themselves are kept alive one extra cycle because raster tasks hold raw pointers to them during execute). A new regression test (core/cpu_raster_cache_lifetime) reproduces the stale-host scenario with a poisoned arena and passes with the fix.Please retest on latest master once the fix lands. If it still crashes, sharing the model export config (llmexport command / config.json) would help us reproduce the exact writer of the corrupted slot.
Thanks for digging into this and for the detailed explanation.
The identified cache lifetime issue matches the behavior I was seeing very closely.Once the fix is merged, I’ll retest on the same setup: Xiaomi 12X, Qwen3.5-4B, CPU backend, /v1/chat/completions, sequential non-streaming requests.
I’ll run a longer sequence of requests and report back whether the crash is gone. If it still reproduces, I can also share the model export config as suggested.
Thanks again for the investigation and regression test.
可以拿这个分支 feature/cpu-resize-cache-scope 再次测试一下，看看问题有没有解决
Hi,
I am testing MNN Chat on Android as a local OpenAI-compatible API server and I am seeing a reproducible native crash during repeated sequential inference.
The model can stay loaded and idle for several hours without issues. However, after sending 1–2 requests to /v1/chat/completions, MNN Chat sometimes freezes and the whole process exits.
The requests are not concurrent — I always wait until the previous request has fully completed.
Device / environment
Xiaomi 12X (psyche)
Android 13
ROM: V816.0.9.0.TLDEUXM
ABI: arm64
Package: com.alibaba.mnnllm.android.release
Model: Qwen3.5-4B
Backend: CPU
API: /v1/chat/completions
stream: false
Crash
Fatal signal 6 (SIGABRT)
Abort message: 'Pointer tag for 0x3f9760004091c000 was truncated'
mnn_crash.txt
mnn_log.txt
libc.so (abort)
libc.so (free)
libMNN.so (MNN::DeferBufferAllocator::apply())
libMNN.so (MNN::Session::resize())
libMNN.so (MNN::Transformer::Llm::forwardRaw(...))
libMNN.so (MNN::Transformer::Llm::generate(...))
libMNN.so (MNN::Transformer::Llm::response(...))
libmnnllmapp.so (mls::LlmSession::ResponseWithHistory(...))
The API stack continues through:
ResponseHandler.processNonStreamGeneration
MNNChatService.processLlmGeneration
RequestQueueManager.processRequest
After the crash, adb shell pidof com.alibaba.mnnllm.android.release returns no PID, so the whole application process has terminated.
This looks like a native memory-management issue during repeated LLM generation/session resize rather than an Android low-memory kill.
I can attach the full adb logcat and adb logcat -b crash output if useful.
Expected: sequential API requests should remain stable.
Actual: repeated inference can trigger SIGABRT inside libMNN.so and terminate the app.