[C] Fix: `cuvsRMMMemoryResourceReset` sets a valid resource
In cuvsRMMMemoryResourceReset, we currently call rmm::mr::set_current_device_resource(nullptr); but this generates segfaults (more specifically, a tentative to dereference a NULL pointer)
We should either save the original resource we get inside cuvsRMMPoolMemoryResourceEnable (returning some state, e.g. via a new cuvsRMMMemoryResource_t -- which may be get rid of the thread local too, if we find it convenient), and pass it back to cuvsRMMMemoryResourceReset so it can restore it.
Or reset the resource to some initial, valid instance.
The new rmm::mr::reset_current_device_resource_ref() (see https://github.com/rapidsai/rmm/blob/f965b7f98805e96ccd4fb3e7774f9b8e38ad2bdb/cpp/include/rmm/mr/per_device_resource.hpp#L466) does that.
This PR follows the second approach and replicates reset_current_device_resource_ref behaviour in cuvsRMMMemoryResourceReset, by resetting the current device resource to rmm::mr::detail::initial_resource().
Fixes https://github.com/rapidsai/cuvs/issues/1454
This pull request requires additional validation before any workflows can run on NVIDIA's runners.
Pull request vetters can view their responsibilities here.
Contributors can view more details about this message here.
Ah, I'm not on @rapidsai/cuvs-cpp-codeowners. @benfred: This might need a quick gander.
/ok to test 0f6df12
@robertmaynard @benfred Rebased on release/25.12, now the changeset is clean
Hi, @ldematte.
I'll mention this here before @cjnolet does: For RAPIDS projects, the recommendation is not to do force pushes, to prevent review comments from disappearing, etc.
@mythrocks I usually don't do that, but in case of a rebase to another branch (main -> 25.12 in this case) this is necessary (I think? If you know a better way, please correct me!)
/ok to test c486f11
in case of a rebase to another branch...
Fair point. And in this case, the prior review comments remained intact, so there's no adverse consequence.
Argh. It looks like we need to run pre-commit to fix the formatting in the C test file.
That's very strange, I have installed the pre-commit hook. Maybe it got updated? Anyway, will run it
/ok to test e0a78ed
/merge