-
Notifications
You must be signed in to change notification settings - Fork 758
CPU->GPU copy of a default-initialized vector [windows/vs2019] #1275
Comments
This looks like an easy enough fix -- wrapping the call to |
Great! I'm looking forward to 1.11.0! (attn @nvibd to include this patch into our temporary working version too) |
I'm having trouble reproducing this. What arguments are being passed to nvcc? |
I created a default cuda project in Visual Studio 2019 (using the "Cuda 11.0 Runtime" template) and then changed the "kernel.cu" file to match the code above. The assertion is triggered on run in debug|x64 configuration. This is the entire command line from the build window:
This is exactly what comes out of the VS template, as I didn't change any of the default options. FYI, I was a bit puzzled by the additional include directory |
Thanks -- I can reproduce it here with those flags. |
…ements Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode. Fixes NVIDIA#1275
I've fixed this one, though compiling the test suite requires disabling warnings-as-errors to compile with MSVC in debug due to |
Thanks! The MSVC debug warnings is a known bug (#1273 for context). I'm planning to work-around that in the build system for 1.11.0. |
…ements Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode. Fixes NVIDIA#1275
…ements Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode. Fixes #1275
In Windows, with VS2019 16.7.2 (debug mode) and the default thrust provided with CUDA 11 package, I found this problem:
The code triggers an assertion in
vector:46
(standard vector header, provided by Microsoft) coming fromthrust/system/cuda/detail/internal/copy_cross_system.h:106
(it's inside the functioncross_system_copy_n
, and the assert is triggering because the code is dereferencing thebegin()
iterator, which is invalid (being the vector empty), and more specifically is nullptr (being uninitialized).The problem disappears if the
gpu
vector is allocated (e.g. by pushing back and clearing) before the assignment:I think this might be loosely related to #938 and #939 .
The other assertion I mentioned above has been fixed by @allisonvacanti here (b9a2073)
The text was updated successfully, but these errors were encountered: