Jos*_*nan 9 python gpu pytorch
我看过很多针对特定案例特定问题的特定帖子，但没有基本的动机解释。这是什么错误：
RuntimeError: CUDA error: device-side assert triggered
意思？具体来说，正在触发的断言是什么，为什么断言在那里，我们如何向后工作以调试问题？
按原样，此错误消息在诊断任何问题时几乎无用，因为它似乎是在说“某处触及 GPU 的某些代码”有问题。Cuda 的文档在这方面似乎也没有帮助，尽管我可能是错的。 https://docs.nvidia.com/cuda/cuda-gdb/index.html
当我将代码转移到 CPU 而不是 GPU 上工作时，出现以下错误：
IndexError: index 128 is out of bounds for dimension 0 with size 128
因此，代码中可能存在错误，由于某种奇怪的原因，该错误会显示为 CUDA 错误。
当 CUDA 设备代码运行时检测到设备端错误时，该错误将通过通常的CUDA 运行时 API 错误报告机制报告。设备代码中通常检测到的错误类似于非法地址（例如，尝试取消对无效指针的引用），但另一种类型是设备端断言。每当 C/C++assert()设备代码中出现并且断言条件为假时，就会。
这种错误是由特定内核引起的。CUDA 中的运行时错误检查必然是异步的，但可能至少有 3 种可能的方法来开始调试。
修改源代码以有效地将异步内核启动转换为同步内核启动，并在每次内核启动后进行严格的错误检查。这将识别导致错误的特定内核。此时，只需查看该内核代码中的各种断言就足够了，但您也可以使用下面的第 2 步或第 3 步。
使用cuda-memcheck. 这是一个类似于“设备代码的valgrind”的工具。当您使用 运行代码时cuda-memcheck，它往往会运行得更慢，但运行时错误报告将得到增强。通常也最好使用-lineinfo. 在这种情况下，当触发设备端断言时，cuda-memcheck将报告断言所在的源代码行号，以及断言本身和为假的条件。您可以在此处查看使用它的演练（尽管使用非法地址错误而不是assert()，但过程assert()将类似。
也应该可以使用调试器。如果您使用诸如cuda-gdb（例如在 linux 上）之类的调试器，则调试器将具有回溯报告，该报告将指示断言是哪一行，何时被命中。
两个都 cuda-memcheck并能如果CUDA代码从一个python脚本启动所使用的调试。
此时您已经发现断言是什么以及它在源代码中的位置。为什么它在那里无法笼统地回答。这将取决于开发人员的意图，如果没有注释或以其他方式明显，您将需要一些方法来以某种方式直觉。“如何向后工作”的问题也是一个通用的调试问题，并非特定于 CUDA。您可以printf在 CUDA 内核代码中使用，也可以使用调试器cuda-gdb来协助处理（例如，在断言之前设置断点，并在断言即将被命中时检查机器状态 - 例如变量）。