[Resolved] Problem Misaligned address and Invalid addres


I fight with these two problems for hours and don’t find the solution. Sometimes works, sometimes don’t with the same data. Can anybody help me?

If I remove the “loop” from the code fragment below everything works, but I need becouse is a density of volumetric light effect.

//light struct used
struct Light
float3 Position;
int Type;
float3 Direction;
float Range;
float3 Color;
float Strength;
float3 AreaLightCenter;
float ConeAngle;
float3 AreaLightExtents;
float ConeDecay;
int CastShadow;
float3 Dummy;

//buffer of light data
rtBuffer<Light, 1> lights;

//volumetric light effect
unsigned int numLights = lights.size();
if (numLights > 0 && prd_radiance.depth == 0 && lights[0].Type == 0 && atmospheric_light_intensity > 0.0f)
//luz volumetrica apenas na luz do sol
Light light = lights[0];
float3 atmosphericLightColor = light.Color * light.Strength;

    for (int i = 0; i < 10; i++)
	float rnd1 = rnd(prd_radiance.seed);
	float rnd2 = rnd(prd_radiance.seed);
	float rnd3 = rnd(prd_radiance.seed);
	float radius = light.AreaLightExtents.x;
	float3 randomPoint = light.AreaLightCenter + ((normalize(make_float3(rnd1, rnd2, rnd3)) * 2.0f - 1.0f) * radius);
	float rndMarch = hitDistance * rnd1;
	float3 mediumPosition = hitPosition - ray.direction * rndMarch;
	float3 shadowRay = randomPoint - mediumPosition;
	float ldist = optix::length(shadowRay);
	shadowRay /= ldist;
	optix::Ray shadow_ray = optix::make_Ray(mediumPosition, shadowRay, shadow_ray_type, scene_epsilon, ldist);
	PerRayData_shadow shadow_prd;
	shadow_prd.attenuation = make_float3(1.0f);
	rtTrace(top_shadower, shadow_ray, shadow_prd);
	prd_radiance.radiance += atmosphericLightColor * atmospheric_light_intensity * shadow_prd.attenuation;

Optix: 3.9.1
GPU: Geforce GTX 780
Driver Date: 24/11/2016
Driver Version:


Hi Daniel,

Have you tried enabling OptiX exceptions to see if they provide any more info? Here are the steps, for reference:

  1. Enable all exceptions in the context.
  2. Add an exception program (see the SDK for some examples)
  3. If your exception program calls rtPrintExceptionDetails, then also enable the OptiX internal print buffer.

Something like this in the C API:

rtContextSetExceptionEnabled( context, RT_EXCEPTION_ALL, 1);
rtContextSetExceptionProgram( context, entry_point, program );
rtContextSetPrintEnabled( context, 1);

You could also run your code through OptiX 4 and see if you get the same crash.

If none of that works, then please email optix-help and we can dig into it with a trace or source. A simple reproducer in the style of an SDK sample would be very welcome in that case.

Additionally there are at least two general problems in your code.

1.) This potentially fails for too small ldist and could produce invalid ray exceptions.

shadowRay /= ldist; // Protect against too small ldist!

2.) Your sampling method will produce a random number correlation between your sphere sampling and the volume sampling along the view direction!
Uniform sampling of a sphere can be done with two random numbers only and a separate third random number should be used for the volume density sampling.

float3 randomPoint = light.AreaLightCenter + ((normalize(make_float3(rnd1, rnd2, rnd3)) * 2.0f - 1.0f) * radius); 
float rndMarch = hitDistance * rnd1; // Correlates with the sphere sample point!

Then there are some performance optimizations possible:
This is a copy operation! A const reference would be faster, especially if you only use few of the fields.

Light light = lights[0]; // Use Light const& light = lights[0]; instead

If light color and strength aren’t used anywhere else separately I would fold this into color on the host and remove the strength field.

float3 atmosphericLightColor = light.Color * light.Strength;

atmosphericLightColor * atmospheric_light_intensity could be calculated outside the loop.

prd_radiance.radiance += atmosphericLightColor * atmospheric_light_intensity * shadow_prd.attenuation;

If you didn’t find the issue with the exceptions, I would also recommend to update the display driver to the newest available version as well. At this time that should be 376.33. I have been using this with OptiX 3.9.1 and 4.0.2 without issues so far.

Hi and thanks for answers.

dlacewell I enable all exceptions in my debug environment and becouse of this the problem did not occur, the process returned some Stack_Overflow but did not crashing. When I enable exception in release mode the same happened.

Detlef Roettger I made the changes you suggested and thanks for the list.

To resolve the problem I have to change my stack size from 5000 to 6000. This size is acceptable? In the examples the values are much smaller, but with rays to Reflection, Refraction, GI, AO, Shadows, etc… I did not find a way to do this.

I tried to remove the recursion, but this is very difficult to do and I did not succeed.

Any suggest about this?

Thank you.

Yes, a stack size of 5000 or 6000 is not uncommon in more complex applications.
Depending on the PerRayData payload size, the amount of local variables, and the number of recursions you use, this might just be necessary.
The stack will take quite some VRAM on GPUs with many cores! Don’t overdo it.

That list is also exactly what you could attack if you’d like to reduce the required stack size.
Using iterative algorithms over recursive ones should help the most. E.g. Monte Carlo path tracing instead of Whitted recursive ray tracing.
Try to make the per ray payload as compact as necessary and reduce the number of live variables around rtTrace or callable program calls.

The OptiX Programming Guide chapter on performance guidelines mentions this and some more tips.

Marking as resolved since the original problem was due to stack overflow.

Btw, the stack overflow exception is enabled by default. You can leave a simple exception program attached to catch it.

Yes, I enabled stack overflow and invalid ray to prevent service crashing.

Evrething works fine now.


What I meant is that the stack overflow exception should be enabled be default; you do not need to call rtContextSetExceptionEnabled() if this is the only exception you care about.

Also, it’s fine to leave other exceptions (e.g., invalid ray exception) enabled while debugging, but remember to turn them off in your final build. There is a performance penalty to having a lot of exceptions enabled in OptiX 4.0.