the likely bug with Optix3.0.1

I have developped application programs with Optix3.0.1 for almost one year, however, recently I met a problem.
My application program is quite complicated, so I won’t talk about it, but I will depict my problem related my program briefly . Now let’s begin, it is quite an easy task.
I want to pass an integer into the ray_generation program, then in the ray_generation program, memories will be allocated with the passed number,
at last, I would like to initialize the memeories with values. But it can’t work normally, the debug information is that:

Unhandled exception at 0x0fbe9936 in NIMCAsst.exe: 0xC0000005: Access violation reading location 0x00000014."

The codes contributing to the exception is as follow.
In the Main funciton,I declare a variable

context["number"]->setUint(2);

And in the xx.cu file

rtDeclareVariable(uint,number,,);

Then in the ray_generation program

unsigned int * ab =new unsigned int[number];
ab[0] = 1;

After some experiments, I found the critical code is “ab[0]=1”,if I delete the “ab[0]=1”,it works normally, otherwise it will pop up an exception given above,
I’m not quite sure what’s wrong with it, is there someone can give me a suggestion. How can I fix the problem? Thank you for your answers

Supplement: Operate System :Windows7
development tool: Vs2010
GPU : GTX650

Dynamic memory allocations inside OptiX CUDA programs are not supported.

See OptiX Programming Guide Chapter 12 Caveats:
“Use of the CUDA malloc, free, and printf functions within a program is not supported.”

Means the problem is the “new”. As long as you won’t access the data the compiler will eliminate it as dead code.

Since you know the amount of memory beforehand, because you control it with the number value, you could allocate your whole memory by creating a single output buffer (or input_output buffer if you also read it) with number * launchDim.x * launchDim.y * sizeof(unsigned int) size on the host resp. change the size of that buffer according to number and then calculate the proper pointer *ab per launchIndex inside your ray generation program and continue from there.

Try if resizing that buffer induces a recompile. If yes, that would be a slow operation and depending on how often your number value changes, you could only grow the buffer and avoid shrinking it as a performance optimization.

Thank you for answering the question.
Actually,the value of “number” is unknown in the host code, it is calculated in the device code.Then
memory corresponding to the valude will be allocated, in this way, it’s not a good choice to define a
buffer.
If optix don’t have access to dynamic memory allocation,I have to define an array with const number which
is far more larger than the value of “number”, unfortunately, which will create extra memory unused. It
sounds like a bad idea when taking the limited memory size of the device into consideration.To be frank, it is really
a bad idea that the optix can’t handle dynamic memory allocation.

unsigned int ab[100];// 100 is larger than number to ensure