origin/main fails the sanitize-cpu (address,undefined) CI lane. Same five tests on main @e17e8f8a (job 93567297949) and on every branch built from it:
9 - test_load_direct_upload (Failed)
44 - test_llama_embedding_fold (Failed)
59 - test_laguna_nvfp4_loader (Failed)
234 - test_openai_api_server (Failed)
238 - test_capi (Failed)
All five are the same UBSan class, misaligned address ... for type 'short unsigned int', which requires 2 byte alignment — an unaligned uint16_t (bf16) load:
| site |
form |
src/vt/cpu/cpu_ops.cpp:33:70 |
load of misaligned address (hit by 3 of the 5) |
src/vllm/model_executor/models/laguna.cpp:1028:56 |
load of misaligned address |
tests/vllm/test_load_direct_upload.cpp:177:48 |
reference binding to misaligned address |
Likely origin. ENG-LOAD-DIRECT-UPLOAD (#150) made the loaders BORROW safetensors mmap bytes instead of copying them. A copy lands in a freshly-allocated, suitably-aligned buffer; a borrowed view inherits whatever offset the file header put it at, and a safetensors data offset carries no 2-byte alignment guarantee. Reinterpreting those bytes as uint16_t is then UB even where every real CPU tolerates it — which is exactly why only the UBSan lane sees it, and why the ordinary ctest lane is green.
Not diagnosed further here and deliberately not fixed in passing: found while repairing the unrelated device-leakage ratchet (#298, PR #300), and it is a different defect class with its own blast radius across the load path.
Note the lane has been red for a while, so a passing sanitize-cpu is not currently a signal any PR can produce. Any fix wants a red-first reproduction on one of the five, then memcpy-based reads (or an alignment guarantee at borrow time) rather than a suppression.
origin/mainfails thesanitize-cpu (address,undefined)CI lane. Same five tests on main @e17e8f8a(job 93567297949) and on every branch built from it:All five are the same UBSan class,
misaligned address ... for type 'short unsigned int', which requires 2 byte alignment— an unaligneduint16_t(bf16) load:src/vt/cpu/cpu_ops.cpp:33:70load of misaligned address(hit by 3 of the 5)src/vllm/model_executor/models/laguna.cpp:1028:56load of misaligned addresstests/vllm/test_load_direct_upload.cpp:177:48reference binding to misaligned addressLikely origin.
ENG-LOAD-DIRECT-UPLOAD(#150) made the loaders BORROW safetensors mmap bytes instead of copying them. A copy lands in a freshly-allocated, suitably-aligned buffer; a borrowed view inherits whatever offset the file header put it at, and a safetensors data offset carries no 2-byte alignment guarantee. Reinterpreting those bytes asuint16_tis then UB even where every real CPU tolerates it — which is exactly why only the UBSan lane sees it, and why the ordinaryctestlane is green.Not diagnosed further here and deliberately not fixed in passing: found while repairing the unrelated
device-leakageratchet (#298, PR #300), and it is a different defect class with its own blast radius across the load path.Note the lane has been red for a while, so a passing
sanitize-cpuis not currently a signal any PR can produce. Any fix wants a red-first reproduction on one of the five, thenmemcpy-based reads (or an alignment guarantee at borrow time) rather than a suppression.