Fix rocSPARSE handle and test buffer leaks under ASAN (#388)

[zjin-lcf]

Summary

Fixes handle/memory leaks in the ROCm (HIP) backend that LeakSanitizer reports under -DRESOLVE_USE_ASAN=yes. LSan attributes the allocation sites to librocsparse.so / librocsolver.so, which makes them look like AMD defects, but they are actually caused by ReSolve creating rocSPARSE/rocSOLVER handles (and a device matrix) that it never destroys.

Note (updated): The earlier version of this PR claimed the only remaining leaks were external ROCm runtime-init allocations. That was only true for the reduced test matrix used at the time (KLU was disabled, so the rocSOLVER-Rf refactorization tests were never built or run). Enabling KLU surfaced an additional ReSolve-owned leak in LinSolverDirectRocSolverRf, now fixed here.

Changes

• resolve/LinSolverDirectRocSparseILU0.cpp: setup() creates descr_A_, descr_L_, descr_U_, info_A_, and a device analysis buffer_, but the destructor only freed the ILU value/aux device arrays. Destroy the three matrix descriptors and the info object and free buffer_ on teardown.
• resolve/LinSolverDirectRocSolverRf.cpp: setup() creates the rocSOLVER refactorization info object infoM_ (rocsolver_create_rfinfo) and the combined-factor matrix M_ (new matrix::Csr in combineFactors), but the destructor freed neither, and repeated setup() calls leaked both again. Now: destroy infoM_ and delete M_ in the destructor, destroy any previous infoM_ before recreating it in setup(), and delete any previous M_ before reallocating it. This mirrors the existing CUDA teardown (LinSolverDirectCuSolverGLU deletes M_; CholeskySolverHip destroys its rfinfo).
• tests/unit/matrix/SparseTests.hpp: copyValues allocated a host scratch buffer with new[] in the device path and never freed it. Free it in the device case (on host it aliases matrix-owned data and must not be freed).
• tests/lsan.supp (new): LSan suppression file for the residual, external ROCm runtime-init allocations that are not fixable from within ReSolve.

Test plan

Environment: AMD Instinct MI300A (gfx942), ROCm 7.2.4.

cmake -DRESOLVE_USE_ASAN=yes -DRESOLVE_USE_UBSAN=yes -DCMAKE_BUILD_TYPE=RelWithDebInfo \
      -DRESOLVE_USE_HIP=yes -DCMAKE_HIP_ARCHITECTURES=gfx942 -DRESOLVE_USE_KLU=yes ..
make -j && ctest -j

• ILU0 / test buffer: before, all rocsparse_create_mat_descr / rocsparse_create_mat_info leaks present and sparse_matrix_test leaks a host buffer; after, gone.
• rocSOLVER-Rf (rocsolver_rf_test, requires KLU): before 1169156 B / 139 allocs (LSan names combineFactors ... :338 → M_ and its Csr::allocateMatrixData children, plus rocsolver_create_rfinfo → infoM_); after 6192 B / 108 allocs.
• After all fixes, no ReSolve-attributed leaks remain in any test.

Remaining leaks (external ROCm runtime init, suppressed)

The only residual LSan output is a fixed ~6 KB inside libhsa-runtime64.so / libamdhip64.so. Symbolizing against the library's embedded .gnu_debugdata:

rocr::AMD::hsa_amd_signal_create        4704 B / 84 objs + 864 B / 12 objs
hsaKmtCreateEventCtx                     480 B / 10 objs (indirect; backs the signals)
rocr::HSA::hsa_queue_create -> GpuAgent::QueueCreate -> AqlQueue::AqlQueue   72 B (+ children)

These are one-time HSA/HIP runtime-initialization allocations owned by the process-global rocr::core::Runtime singleton; HIP never calls hsa_shut_down() at exit, so LSan flags them. They are:

• External to ReSolve (no ReSolve/rocSPARSE/rocBLAS/rocSOLVER frames), and
• Not a growing leak — a standalone HIP program (no ReSolve) doing H2D + kernel + D2H in a loop reports an identical 6072 B / 106 allocations for 1, 100, and 1000 iterations, confirming this is init-only and distinct from the growing signal leak in [Issue]: HSA signal leak in hipMemcpy causes continuous host memory growth ROCm/ROCm#5921.

AMD's own GPU sanitizer docs classify these language-runtime allocations as "not considered to be leaks" and recommend exactly this suppression-file approach, which tests/lsan.supp implements.

Relationship to #388

This does not fully close #388, but it eliminates all ReSolve-owned leaks in the HIP backend (ILU0 handles, rocSOLVER-Rf infoM_/M_, and the test host buffer). The remaining LSan reports are exclusively the external, one-time ROCm runtime-init allocations covered by tests/lsan.supp.

[superwhiskers]

this will not close #388, but it does reduce the leak load

[superwhiskers]

i think the leak suppression list added there is too broad. unless i'm misunderstanding how the suppression list works, that will, in addition to hiding the runtime globals, also hide future rocm adjacent leaks because it targets the shared objects and not the individual functions responsible for the leak

[pelesh]

@zjin-lcf thanks for your contribution. Please provide your before and after test logs with instructions how to reproduce them. Also, please go through Re::Solve PR checklist available in the PR template.