The “strangeness” of the error reporting is most likely due to the asynchronous execution of CUDA kernels and since e.g. print statements might be synchronizing, you might indeed either mask or avoid the issue. Especially if you are dealing with race conditions, changing the execution order or speed could “hide” the memory violation and the illegal memory reads or writes could not be hit.
cuSOLVER was already activated for a lot of methods as described in this blog post, but due to some performance issues were still seeing compared to MAGMA (we are working with cuSOLVER to accelerate these methods), MAGMA is still used for some workloads.
However, since you are apparently seeing the IMA in MAGMA, we might consider trading a slower execution in cuSOLVER for this functional issue in MAGMA.
EDIT: just as one example of debugging a race: some time ago I was also hunting down an invalid output of another method and was able to reproduce it only when I’ve pushed the GPU utilization to max. in another process, which then slowed down the faulty code and allowed me to narrow down a missing CUDA stream synchronization.