Skip to content
This repository has been archived by the owner on Mar 21, 2024. It is now read-only.

CPU->GPU copy of a default-initialized vector [windows/vs2019] #1275

Closed
mfoco opened this issue Sep 16, 2020 · 7 comments · Fixed by #1329
Closed

CPU->GPU copy of a default-initialized vector [windows/vs2019] #1275

mfoco opened this issue Sep 16, 2020 · 7 comments · Fixed by #1329
Assignees
Labels
good first issue Good for newcomers. P1: should have Necessary, but not critical. type: bug: functional Does not work as intended.
Milestone

Comments

@mfoco
Copy link

mfoco commented Sep 16, 2020

In Windows, with VS2019 16.7.2 (debug mode) and the default thrust provided with CUDA 11 package, I found this problem:

int main()
{
    thrust::device_vector<int> gpu;
    std::vector<int> cpu;
    gpu = cpu; // assertion in debug
}

The code triggers an assertion in vector:46 (standard vector header, provided by Microsoft) coming from thrust/system/cuda/detail/internal/copy_cross_system.h:106 (it's inside the function cross_system_copy_n, and the assert is triggering because the code is dereferencing the begin() 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:

#include <thrust/device_vector.h>

int main()
{
    thrust::device_vector<int> gpu;
    std::vector<int> cpu;
    gpu.push_back(1);
    gpu.clear();
    gpu = cpu; // works! (actually, the CUDA11 version triggers a different assertion, but that has been fixed already)
}

I think this might be loosely related to #938 and #939 .

The other assertion I mentioned above has been fixed by @allisonvacanti here (b9a2073)

@alliepiper
Copy link
Collaborator

This looks like an easy enough fix -- wrapping the call to trivial_device_copy with if (n > 0) { ... } should do the trick.

@alliepiper alliepiper self-assigned this Sep 16, 2020
@alliepiper alliepiper added this to the 1.11.0 milestone Sep 16, 2020
@mfoco
Copy link
Author

mfoco commented Sep 17, 2020

This looks like an easy enough fix -- wrapping the call to trivial_device_copy with if (n > 0) { ... } should do the trick.

Great! I'm looking forward to 1.11.0! (attn @nvibd to include this patch into our temporary working version too)

@alliepiper
Copy link
Collaborator

I'm having trouble reproducing this. What arguments are being passed to nvcc?

@alliepiper alliepiper added the info needed Cannot make progress without more information. label Sep 17, 2020
@mfoco
Copy link
Author

mfoco commented Sep 18, 2020

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:

"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\bin\nvcc.exe" -gencode=arch=compute_52,code=\"sm_52,compute_52\" --use-local-env -ccbin "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.27.29110\bin\HostX86\x64" -x cu   -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\include" -I"C:\vcpkg\installed\x64-windows\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\include"  -G   --keep-dir x64\Debug -maxrregcount=0  --machine 64 --compile -cudart static  -g   -DWIN32 -DWIN64 -D_DEBUG -D_CONSOLE -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /Fdx64\Debug\vc142.pdb /FS /Zi /RTC1 /MDd " -o x64\Debug\kernel.cu.obj "C:\Users\pan\source\repos\cuda-assign-repro\cuda-assign-repro\kernel.cu"

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 C:\vcpkg\installed\x64-windows\include so I wanted to check its content, but the directory doesn't even exists (nor C:\vcpkg\installed\x64-windows exists). That shouldn't be a problem.

@alliepiper alliepiper added type: bug: functional Does not work as intended. and removed info needed Cannot make progress without more information. labels Sep 18, 2020
@alliepiper
Copy link
Collaborator

Thanks -- I can reproduce it here with those flags.

@alliepiper alliepiper added the P1: should have Necessary, but not critical. label Oct 7, 2020
@alliepiper alliepiper removed their assignment Oct 7, 2020
@alliepiper alliepiper added the good first issue Good for newcomers. label Oct 7, 2020
@alliepiper alliepiper modified the milestones: 1.11.0, 1.11.1 Oct 7, 2020
bjude added a commit to bjude/thrust that referenced this issue Oct 24, 2020
…ements

Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode.

Fixes NVIDIA#1275
@bjude
Copy link
Contributor

bjude commented Oct 24, 2020

I've fixed this one, though compiling the test suite requires disabling warnings-as-errors to compile with MSVC in debug due to
F:\code\thrust\thrust/detail/allocator/allocator_traits.inl(369): warning #3056-D: calling a __host__ function("std::_Iterator_base12::_Iterator_base12") from a __host__ __device__ function("std::_Vector_const_iterator< ::std::_Vector_val< ::std::_Simple_types<signed char> > > ::_Vector_const_iterator") is not allowed

@alliepiper
Copy link
Collaborator

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.

@alliepiper alliepiper modified the milestones: 1.11.1, 1.11.0 Oct 24, 2020
alliepiper pushed a commit to bjude/thrust that referenced this issue Oct 24, 2020
…ements

Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode.

Fixes NVIDIA#1275
alliepiper pushed a commit that referenced this issue Nov 5, 2020
…ements

Attempting to perform this copy with 0 elements caused a debug assertion when compiling with MSVC in debug mode.

Fixes #1275
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers. P1: should have Necessary, but not critical. type: bug: functional Does not work as intended.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants