fix(arrow/cdata): Handle errors to prevent panic#614
Conversation
zeroshade
left a comment
There was a problem hiding this comment.
Looks good, can you add a test for this please?
|
Thanks! Assuming no issues in CI i'll merge this |
|
Looks like you have some test failures here |
|
@zeroshade please review it |
|
I have resubmitted the code based on the error messages, and the tests passed successfully on my local mechine. |
|
@xiaocai2333 looks like there's a memory leak found by the leak sanitizer that needs to be addressed. I can poke at it tomorrow if you need help tracking it down. Specifically, the 48 bytes leaks are likely ArrowSchema objects that aren't getting freed (probably children in a nested test) |
Signed-off-by: Cai Zhang <cai.zhang@zilliz.com>
b9d4cd3 to
557f8a0
Compare
|
@zeroshade hi, I have fixed the memory leak and verified it locally. Could you please approve this to run the CI workflows? |
Port of apache/arrow-go#614 to v17. When importing a C Data Interface array with children (e.g., a record batch as a struct array), `doImport()` had a deferred `C.free(imp.arr)` that fired when `imp.data == nil` (import error). For child importers, `imp.arr` points into the parent's contiguous SmallVector allocation (an interior pointer), not a standalone malloc'd pointer. Calling `C.free()` on this interior pointer triggers ASan bad-free and causes heap corruption in production. Fix: 1. Remove the `C.free` defer from `doImport()` entirely. 2. Introduce `importAllocator.forceRelease()` which always frees the root-level malloc'd ArrowArray (via `importAllocator.arr`), never child interior pointers. Uses atomic CAS to ensure single execution. 3. In `doImportArr`, call `forceRelease()` on error or when bufCount==0. 4. Propagate errors from `importChild()` in STRUCT, DENSE_UNION, and SPARSE_UNION cases (previously silently ignored). 5. Release already-imported child data on error in `doImport()`. Ref: apache/arrow-go#613, apache/arrow-go#614 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: chyezh <chyezh@outlook.com>
Rationale for this change
Fixes: #613
What changes are included in this PR?
Return error correctly.
Are these changes tested?
Yes
Are there any user-facing changes?
No