#3814 Handle bad_allocs in unpackVolumeFaces

[akleshchev]

Handle bad_allocs in unpackVolumeFaces

[Copilot]

Pull request overview

This PR hardens LLVolume::unpackVolumeFaces() against memory-allocation failures and implausible compressed payload sizes while unpacking mesh volume faces, aiming to avoid crashes and improve resiliency during mesh streaming/decode.

Changes:

• Added a compressed-size sanity check (rejecting non-positive or very large inputs) before attempting unzip/decode.
• Wrapped unzip + decode in try/catch to handle std::bad_alloc, std::exception, and unknown exceptions with logging and safer failure behavior.
• Introduced mainloop WorkQueue posting for the small-mesh OOM path to surface an OOM user warning / fatal on the main loop.

Suppressed comments (1)

indra/llmath/llvolume.cpp:2416

• main_queue->post() can fail (e.g. if the queue is closed) and the return value is currently ignored, which can drop the out-of-memory handler in the “small mesh” path. Please check the return value and fall back to a local warning when posting fails.

                const LLUUID mesh_id_copy = mesh_id; // capture by value for the lambda
                main_queue->post([mesh_id_copy, size]()
                {
                    LLError::LLUserWarningMsg::showOutOfMemory();
                    LL_ERRS("MeshStreaming") << "Out of memory unpacking mesh id " << mesh_id_copy

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[akleshchev]

Will fix. But if main_queue is closed, we are shuting down and don't really care, memory will be freed soon.