zero grown entries in loader_resize_generic_list

[aizu-m]

Tracing how the loader's internal object lists get their zero-fill guarantee across the two allocator paths.

loader_calloc zeroes on both paths:

// allocation.c, app-allocator branch
pMemory = pAllocator->pfnAllocation(...);
if (pMemory) memset(pMemory, 0, size);

loader_realloc only zeroes the grown tail on the default branch:

// allocation.c, default branch
pNewMem = realloc(pMemory, size);
if (NULL != pNewMem && size > orig_size)
    memset((uint8_t *)pNewMem + orig_size, 0, size - orig_size);
// the pfnReallocation branch has no matching memset

loader_resize_generic_list doubles a list and then trusts the new half to read as zero. That holds with the default allocator. It does not hold when the app supplies a VkAllocationCallbacks with pfnReallocation, since the callback is not obliged to zero grown memory.

These lists are indexed sparsely. icd_term->surface_list grows past its initial 32 slots once more than 32 surfaces are live. wsi_unwrap_icd_surface then reads surface_list.list[surface_index] and treats a non-null value as an already-created ICD surface, so an uninitialised slot makes it skip lazy creation and hand a garbage handle to the driver. The debug messenger lists have the same shape.

loader_get_next_available_entry already zeroes its own grown half after the resize instead of trusting the allocator. This moves that guarantee into the resize helper so every list gets it. Valid-input behaviour is unchanged for the default allocator.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

Author aizu-m not on autobuild list. Waiting for curator authorization before starting CI build.

[ci-tester-lunarg]

CI Vulkan-Loader build queued with queue ID 27864.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3607 running.

[ci-tester-lunarg]

CI Vulkan-Loader build # 3607 passed.