【已解决】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的处理越来越得心应手,至少找到了其解决方法以及解决的过程应该是怎么样的。

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

        大概就这么多了吧,下次见!

你可能感兴趣的:(Bugs(程序报错),python,人工智能,linux,pytorch,机器学习,神经网络,服务器)