Add memory exhaustion error messages by default + improve return values to track them

[GoogleCodeExporter]

While tracking down an "unspecified launch failure" error message after a 
cudppCompact() i found out that: By default the libcudpp is build without 
checking the return values from cudaMalloc() calls.
Thus not checking if the call succeeds and we got a valid device pointer for 
later use.

What steps will reproduce the problem?
1. Setup a cudppCompact with hugh data fields. Example file below.
2. Make any CUDA call (cudaFree for ex.) afterwards and inspect the result 
value.
3. See an "unspecified launch failure" raising.

What is the expected output? What do you see instead?
I would like to be informed from within the cudpp lib that there was an error. 
Which would happen if the #define from the file cutil.h would be enabled by 
default.

What version of the product are you using? On what operating system?
> cudpp 1.1.1
> Linux 2.6.31-gentoo-r6 #1 SMP Mon Jan 18 14:05:18 CET 2010 x86_64 AMD 
Phenom(tm) II X4 940 Processor AuthenticAMD GNU/Linux
> gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3
> nvcc, Cuda compilation tools, release 3.2, V0.2.1221
> VGA compatible controller: nVidia Corporation GT200b [GeForce GTX 275]

Compile instructions for cudpp_memorychecking.cu:
nvcc -L $(CUDPP_LIB_DIR)/ -I$(CUDPP_PATH)/cudpp/include -I/opt/cuda/include 
cudpp_memorychecking.cu -o cudpp_memorychecking -lcudpp_x86_64 -lcuda

Original issue reported on code.google.com by upfeffer...@gmail.com on 16 Feb 2011 at 1:30

Attachments:

• cudpp_memorychecking.cu

[GoogleCodeExporter]

I looked at your example code and tried compiling it. However, I saw that your 
application is not passing the correct number of parameters to cudppPlan() (See 
testrig for examples). You may be using an older version of cudpp. I also 
noticed that you used uint32_t which is typdef'd to unsigned long int. I don't 
think cudpp supports this type.

As far as cudaMalloc() calls, our current implementation does use 
CUDA_SAFE_CALL (which checks for errors) when allocating data within cudpp.

Note: The public interface html's are out-of-date. I'll have to update those. 
But for now please see cudpp_testrig for examples.

Original comment by rites...@gmail.com on 17 Feb 2011 at 12:26

[GoogleCodeExporter]

Ritesh: the new cudppPlan which takes an extra parameter is only in the trunk.  
Most people don't get CUDPP out of svn so they would be using 1.1, not trunk.

Second, CUDA_SAFE_CALL only works in debug mode.

Finally, I assume uint32_t is a 32-bit unsigned integer, which we do support.  
On some platforms unsigned long int is only 32-bits (you have to use unsigned 
long long on windows to get a 64-bit integer, I believe).

Original comment by harr...@gmail.com on 17 Feb 2011 at 12:41

[GoogleCodeExporter]

Since CUDA_SAFE_CALL catches the issue in debug mode, I have updated the type 
to Enhancement.

The enhancement is to return an error code when a cudaMalloc() fails.

Original comment by rites...@gmail.com on 17 Feb 2011 at 5:24

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks, that is what i would like to have. There may be a little too much code 
from my side for such a "small" problem.

Original comment by upfeffer...@gmail.com on 17 Feb 2011 at 9:50

[GoogleCodeExporter]

Original comment by harr...@gmail.com on 6 Jul 2011 at 2:38

• Added labels: Milestone-Release2.1, Priority-High
• Removed labels: Priority-Medium