【已解决】RuntimeError: CUDA error: device-side assert triggeredCUDA kernel errors might be asynchronous

问题描述

        具体报错信息是

• ./aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [0,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [1,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [2,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [3,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [4,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [6,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [8,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [9,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [10,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [11,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [12,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [13,0,0] Assertion `t >= 0 && t < n_classes` failed.
  ../aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [14,0,0] Assertion `t >= 0 && t

• ./aten/src/ATen/native/cuda/Loss.cu:240: nll_loss_forward_reduce_cuda_kernel_2d: block: [0,0,0], thread: [31,0,0] Assertion `t >= 0 && t < n_classes` failed.
  Traceback (most recent call last):
  File "/home/visionx/EXT-3/qfy/project/temp/SimCLR/linear_evaluation.py", line 207, in
  loss_epoch, accuracy_epoch = train(
  ^^^^^^
  File "/home/visionx/EXT-3/qfy/project/temp/SimCLR/linear_evaluation.py", line 75, in train
  acc = (predicted == y).sum().item() / y.size(0)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  RuntimeError: CUDA error: device-side assert triggered
  CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
  For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
  Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions.

原因分析及解决办法

        这个说来也不常见，为什么报这个错呢？壮着胆子去搜了一下，得到如下结果

"RuntimeError: CUDA error: device-side assert triggered" 是由于CUDA内核中的断言错误触发而导致的运行时错误。CUDA内核中的断言通常用于检测代码中的错误或不一致情况，当这些断言失败时，CUDA运行时会抛出此类错误。这种错误可能由多种原因引起，包括以下几种可能性：

1. 程序错误：最常见的原因是你的CUDA程序中存在错误。这可能是由于不正确的设备内存访问、越界访问、线程不正确的同步等问题。你需要检查你的CUDA代码并确保它正确无误。

2. GPU硬件问题：这种错误也可能由于GPU硬件问题引起，例如GPU内存故障或其他硬件故障。如果其他CUDA应用程序在同一GPU上也出现问题，那么硬件问题可能是原因。

3. 不稳定的GPU驱动：某些GPU驱动版本可能不稳定，导致CUDA错误。尝试更新或回滚GPU驱动程序，以查看是否可以解决问题。

4. 内存耗尽：如果你的CUDA程序在GPU内存方面过度使用，可能会导致CUDA错误。确保你的程序不会在GPU内存不足时引发错误。

为了更好地调试和确定问题的来源，错误消息中提到了一些选项。你可以尝试按以下方式进行进一步的调试：

• 设置 CUDA_LAUNCH_BLOCKING=1：这将使CUDA在报告错误时阻塞，以更准确地确定问题的位置。
• 编译时启用 TORCH_USE_CUDA_DSA：这会启用设备端断言，可以提供更多关于问题的信息，但可能会降低性能。

最重要的是，仔细检查你的CUDA代码，确保它正确并且不引发错误。如果问题仍然存在，你可能需要更详细的调试和诊断，以确定问题的根本原因。如果硬件故障是可能的原因，考虑检查GPU的健康状态。

        但遗憾的是我并不明白这说的是什么意思 ，因为就1234所提到的问题我这边是大概率不会存在的，所以这个内容来说就是肯定是软件的问题，但为什么是cuda内核引起的问题呢？想一下和之前的区别：

对我程序来说是cifar10和cifar100区别，也即类别多少的区别

也就是说，我前后的两次操作只有类别上有所不同，但是我却没有更改类别，所以导致了错误，带着这个想法去找新的解决办法，于是我找到了

（1）一开始我在网上查找解决方案，结果大部分网友的解决思路都是类似于这样：

         有人说是造成这个问题的原因就是在做分类任务时，训练数据中存在超出分类数目的标签。举个例子：如果你一共设置了8个类，但是训练数据中的标签里出现了9，就会报这个错误。那么问题来了，这里有一个陷阱。训练数据中的标签含0也会报上述错误。这个就非常诡异了。一般我们都从0开始数，但是在pytorch里0以下的类别标签都是要报错的。所以如果类别标签从0开始，要给所有类别标签都加上1。

         pytorch会自己扫描train_path下的每一个文件夹（每类图片都位于其类别的文件夹下），并将每一个类映射成数值，比如有4类，类别标签就是[0,1,2,3]。在进行二分类的时候的确是将标签映射成了[0,1]，但是在进行4分类的时候，标签却映射成了[1,2,3,4]，因此就会报错。

（2）实际上我按照这种思路去解决并没有用，依然报错同样的问题。后来我仔细查找代码，发现最后原来不是什么标签与分类的类别对不上之类的，而是最后一层网络的代码有问题，你自己要输出是几分类，就应该填写几分类。

 self.outlayer = nn.Linear(256 * 1 * 1, 3)  # 最后的全连接层
 
# 别人是3分类，而我的是5分类，改正这里就解决了
 
 self.outlayer = nn.Linear(256 * 1 * 1, 5)  # 最后是全连接层

（3）其实就是一个小问题，但是搞了老半天，在此记录一下。
————————————————
版权声明：本文为CSDN博主「Penta_Kill_5」的原创文章

         这部分内容给了我启发，于是我在自己的代码里做了一下以下的改变

n_classes = 10  # CIFAR-10 / STL-10

把上面的代码改为下面代码

n_classes = 100  # CIFAR-10 / STL-10

        再跑的话就运行了

完结撒花

        写到这里突然感慨很多，到现在为止，记录自己的bug生涯应该快四个月了，可能是因为太小白的原因，所以看的人并不多，当然也有说技术博客不来csdn的说法，我身边的人几乎没有这上面的会员，相比其他平台的回馈机制，在这里是没有办法得到的，但我还是坚持写了很多并且有几篇优质博客的产生，这是很难得的。

        但自己的成长也是不容忽略的，对bug的处理越来越得心应手，至少找到了其解决方法以及解决的过程应该是怎么样的。

        不足在于对于一些涉及内核和引包问题的解决还是生疏，只有一两次通过改包中代码将问题给解决了，这两次是非常刷新认知的：原来一切皆可改！

        大概就这么多了吧，下次见！