mirror of
https://github.com/opencv/opencv.git
synced 2026-07-27 06:13:05 +04:00
7334957476
predictOptimalVectorWidth() built its vectorWidths table with 8 entries (depths CV_8U..CV_16F), but checkOptimalVectorWidth() indexes it by depth. The 5.x depths CV_16BF, CV_Bool, CV_64U, CV_64S and CV_32U therefore read past the end of the array; the garbage value can slip past the ckercn <= 0 guard, and the divider normalization loop then shifts the divider to zero, so "offsets[i] % dividers[i]" raises SIGFPE. The failure is allocation dependent and shows up as a sequence-dependent crash, e.g. in the OpenCL Norm tests for CV_32U (cv::norm on a UMat reaches this via ocl_sum, which calls predictOptimalVectorWidth before its own depth guard bails out). Size the table to CV_DEPTH_MAX so every depth is in bounds and map the new fixed-size integer depths to their natural OpenCL vector widths; CV_16BF has no OpenCL vector type and stays scalar. Add a regression test covering all depths.