dynafu: zero-initialize Voxel::n in TSDFVolumeCPU::reset() - #4179
Open
shimat wants to merge 1 commit into
Open
Conversation
TSDFVolumeCPU::reset() zeros Voxel::v and Voxel::weight but leaves Voxel::n uninitialized. IntegrateInvoker::operator() reads this uninitialized n and passes it straight into WarpField::applyWarp() whenever warpfield->getNodeIndex() is null, i.e. on any integrate() call before the warp field has registered its first node. applyWarp() then indexes WarpField::nodes (unchecked) n times, so garbage left over in the freshly-allocated Mat can produce an out-of-bounds/wild pointer access. This reproduced as an intermittent SIGSEGV inside applyWarp on macOS arm64 CI in a downstream project (OpenCvSharp), confirmed via crash report: EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0, faulting thread inside WarpField::applyWarp called from IntegrateInvoker::operator() via parallel_for_. Adds a regression test that exercises the vulnerable code path (a single synthetic depth frame, no OpenGL or external test data required) - note that since this is an uninitialized-memory bug, the test cannot deterministically reproduce the crash on every run, but it does guard the specific "first frame, no warp nodes yet" scenario going forward.
shimat
force-pushed
the
fix/dynafu-voxel-n-uninitialized
branch
from
July 17, 2026 03:10
1a83ff4 to
dac5989
Compare
shimat
added a commit
to shimat/opencvsharp
that referenced
this pull request
Jul 17, 2026
cv::dynafu::WarpField::applyWarp crashes intermittently (EXC_BAD_ACCESS/SIGSEGV, confirmed via macOS arm64 CI crash report) because TSDFVolumeCPU::reset() leaves Voxel::n uninitialized; IntegrateInvoker reads it and passes it straight into applyWarp() before the warp field has registered any node. The same signature (a long hang followed by an access violation) also hit Windows x64 CI on this PR, consistent with the same uninitialized-memory bug being non-deterministic across platforms. Upstream fix submitted: opencv/opencv_contrib#4179. Re-enable once that (or an equivalent) fix lands in the submodule pin. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
@savuor Should it be promoted to the main repo somehow? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TSDFVolumeCPU::reset()zerosVoxel::vandVoxel::weightbut leavesVoxel::nuninitialized.IntegrateInvoker::operator()reads this uninitializednand passes it straight intoWarpField::applyWarp()wheneverwarpfield->getNodeIndex()is null - i.e. on anyintegrate()call before the warp field has registered its first node.applyWarp()then indexesWarpField::nodes(unchecked)ntimes, so garbage left over in the freshly-allocatedMatcan produce an out-of-bounds/wild pointer access.This reproduced as an intermittent SIGSEGV inside
applyWarpon macOS arm64 CI in a downstream project (OpenCvSharp), confirmed via crash report:EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0, faulting thread insidecv::dynafu::WarpField::applyWarpcalled fromcv::dynafu::IntegrateInvoker::operator()viaparallel_for_(dispatch_apply).Fix: zero-initialize
Voxel::nalongsidev/weightinreset().Added a regression test in
test_dynafu.cppthat exercises the vulnerable code path (a single synthetic depth frame, no OpenGL or external test data required, unlike the module's existing disabledDynamicFusiontests). Since this is an uninitialized-memory bug, the test can't deterministically reproduce the crash on every run, but it does guard the specific "first frame, no warp nodes yet" scenario going forward.Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.