Raised by the fresh review of LTX-2.5 phase L1 (#435, PR #437) and seconded by the implementer who repaired its findings. Filed as its own issue because it generalizes well past that row.
What was verified
Compiling one offset probe against the old and new include/vllm.h:
|
before |
after |
sizeof(vllm_video_model_params) |
88 |
120 |
sizeof(vllm_video_params) |
96 |
120 |
Every pre-existing field keeps its exact offset (partition 64, device 72, dequant_bf16 76, fp4_resident 80; output_dir 88). The growth is strictly appended, nothing inserted mid-struct. That part is correct and is not in question.
The observation
vllm_video_engine_load unconditionally reads params->family / extra_keys / extra_values / n_extras at offsets 88-115, which is past the end of a binary-old caller's 88-byte object. A guard-page harness demonstrates it:
RESULT: SIGSEGV, the v18 library READ PAST the end of a v12 caller's struct
include/vllm.h says a v12 caller "is byte-identical: it zero-fills the struct growth". That is true for a recompiled caller and not for a binary-old one.
Why this is not an LTX-2.5 item
This is a property of the growth model itself, not of that change. The same "zero-fills the struct growth" language and the same appending pattern appear across v2, v4, v7, v8, v9, v10, v14 and v18. Nothing in the tree pins struct sizes.
It matters because the project ships a .so, carries a test_dlopen "header-less FFI consumer" test, and records c_abi_version in release metadata, so a genuinely binary-old consumer is a shape the project already contemplates.
Not a regression, and no fix is proposed here
The L1 review classified this INFORMATIONAL and the repair was explicitly told not to "fix" it by changing the ABI. This issue exists to own the question for the whole growth model rather than to have each row rediscover it.
Options worth weighing, none chosen: a size or version field the callee checks; pinning sizeof in test_capi so growth is at least deliberate and visible; or documenting recompilation as a stated requirement, which is arguably already the de-facto contract.
🤖 Generated with Claude Code
Raised by the fresh review of LTX-2.5 phase L1 (#435, PR #437) and seconded by the implementer who repaired its findings. Filed as its own issue because it generalizes well past that row.
What was verified
Compiling one offset probe against the old and new
include/vllm.h:sizeof(vllm_video_model_params)sizeof(vllm_video_params)Every pre-existing field keeps its exact offset (
partition64,device72,dequant_bf1676,fp4_resident80;output_dir88). The growth is strictly appended, nothing inserted mid-struct. That part is correct and is not in question.The observation
vllm_video_engine_loadunconditionally readsparams->family / extra_keys / extra_values / n_extrasat offsets 88-115, which is past the end of a binary-old caller's 88-byte object. A guard-page harness demonstrates it:include/vllm.hsays a v12 caller "is byte-identical: it zero-fills the struct growth". That is true for a recompiled caller and not for a binary-old one.Why this is not an LTX-2.5 item
This is a property of the growth model itself, not of that change. The same "zero-fills the struct growth" language and the same appending pattern appear across v2, v4, v7, v8, v9, v10, v14 and v18. Nothing in the tree pins struct sizes.
It matters because the project ships a
.so, carries atest_dlopen"header-less FFI consumer" test, and recordsc_abi_versionin release metadata, so a genuinely binary-old consumer is a shape the project already contemplates.Not a regression, and no fix is proposed here
The L1 review classified this INFORMATIONAL and the repair was explicitly told not to "fix" it by changing the ABI. This issue exists to own the question for the whole growth model rather than to have each row rediscover it.
Options worth weighing, none chosen: a size or version field the callee checks; pinning
sizeofintest_capiso growth is at least deliberate and visible; or documenting recompilation as a stated requirement, which is arguably already the de-facto contract.🤖 Generated with Claude Code