dynafu: zero-initialize Voxel::n in TSDFVolumeCPU::reset()

[shimat]

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 cv::dynafu::WarpField::applyWarp called from cv::dynafu::IntegrateInvoker::operator() via parallel_for_ (dispatch_apply).

Fix: zero-initialize Voxel::n alongside v/weight in reset().

Added a regression test in test_dynafu.cpp that exercises the vulnerable code path (a single synthetic depth frame, no OpenGL or external test data required, unlike the module's existing disabled DynamicFusion tests). 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

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
• The PR is proposed to the proper branch
• There is a reference to the original bug report and related work
• There is accuracy test, performance test and test data in opencv_extra repository, if applicable
  Patch to opencv_extra has the same branch name.
• The feature is well documented and sample code can be built with the project CMake

[asmorkalov]

@savuor Should it be promoted to the main repo somehow?

[fallenmi]

Looks good. The missing initialization is on a real first-frame path: before the warp field has a node index, integration does not overwrite voxel.n, but immediately passes it to WarpField::applyWarp() as the unchecked neighbor count.

I made the failure deterministic by first filling and releasing an allocation with the same 92-byte-per-voxel layout, then running a public-API DynaFu update on a synthetic depth frame. With the exact-base reset behavior (v and weight only), the process segfaults (exit 139). Exact head dac59890f8c7e0f0100424ad98c9d042f2c51eb0 completes the identical poisoned-allocation oracle 20/20 times after resetting n to zero.

The submitted first-frame regression passes 10/10 repetitions, and the complete enabled RGB-D test binary passes 8/8 tests. git diff --check is clean, and the change merges cleanly with current 5.x. The only published status is an old default error without a usable current matrix, so this approval is based on the exact local source/build reproduction above.

Reviewed with OpenAI Codex assistance; I independently verified the exact source path, base/head behavior, current merge, and tests.