oraluben commented on PR #592:
URL: https://github.com/apache/tvm-ffi/pull/592#issuecomment-4493960027
## Updated findings — this is actually an ABI mismatch, not a missing
constructor
After extensive testing, the root cause is **not** that the ErrorObj
constructor fails to initialize
the fields, but rather an ABI mismatch between compile-time and runtime
tvm-ffi.
### Test matrix
| tilelang build (vendored tvm-ffi) | runtime tvm-ffi | Result |
|---|---|---|
| release 0.1.9 (v0.1.3) | 0.1.7 | RC=0 ✓ |
| release 0.1.9 (v0.1.3) | 0.1.8 | SIGBUS |
| release 0.1.9 (v0.1.3) | 0.1.10 | SIGBUS |
| release 0.1.9 (v0.1.3) | 0.1.11 | SIGBUS |
| refactor branch (v0.1.11) | 0.1.10 | RC=0 ✓ |
| refactor branch (v0.1.11) | 0.1.11 | RC=0 ✓ |
### Explanation
v0.1.3: `TVMFFIErrorCell` = 56 bytes (kind, message, backtrace,
update_backtrace)
v0.1.8+: `TVMFFIErrorCell` = 72 bytes (adds cause_chain, extra_context)
When tilelang is compiled against v0.1.3 headers and linked against v0.1.8+
at runtime,
internal struct layouts (TVMFFIAny, TVMFFIObject, TVMFFIErrorCell) can
differ.
The ErrorObj destructor in the runtime binary accesses `cause_chain` at the
v0.1.8+
offset, but the memory at that offset may contain leftover data ("Internal")
from a
different allocation, not the nullptr set by the constructor.
### What this means for this PR
This POC fix (zeroing cause_chain/extra_context in SafeCallContext) is a
**workaround**
that prevents the SIGBUS by defensively clearing the fields — but it doesn't
address
the underlying ABI mismatch. The proper fix is for downstream projects to
ensure their
vendored tvm-ffi headers match the runtime version.
That said, zeroing these fields is still a reasonable defensive measure in
case any
code path ever creates ErrorObj without proper initialization.
@tqchen @junrushao thoughts on whether we should still land this as a safety
net?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
