[Solved] rtTrace() occasionally results in nothing (no call to any hit, miss or exception program)

In some cases rtTrace() doesn’t result in any hit or miss program being called. Ever experienced that? What are the causes?

I am tracing rays (iterative loop) from light source in Cornell scene (as in path_trace sample), out of 16*16 launched threads about 10 get this problem. Once a thread gets this problem all next rtTrace() calls have no effect and the result is infinite loop because exit condition is not set.

I can work around this by stopping the loop not whenever stopping condition is set, but whenever continuation condition is not set (e.g. miss or anyhit wasn’t called). But why would this happen at all in such a simple scene?

Switching acceleration structure builders/traversers didn’t make a difference.

Below is the output log of launch index 1,15 that has this problem (I’m using constant random seed for debugging). Logged data format:
launch Idx - depth - [Gen iter / any hit] - [traced dir / incident dir / hit point / normal / new dir / new origin]

“1,15 - d 1 - G 1 - tra dir” is logged just before rtTrace() in second loop iteration, but there is no logging from any hit or miss programs. It should have been a hit since ray origin is roughly in the middle of floor (rectangle corner coords [0,0] and [556,559]) and direction pointing towards (z component is positive) back wall which is at z = 559.

Here’s the code (generation program loop and miss program with launch index checks before pritfs removed):

for (int i=0;;i++)
{        
  printf("G %d - tra dir %f %f %f\n", ...)
  rtTrace( sceneRootObject, lightRay, lightPrd );

  if (lightPrd.done) 
    break;

  lightRay.origin = lightPrd.origin;
  lightRay.direction = lightPrd.direction;
  printf("G %d - new org %f %f %f\n", ...); // new origin
  printf("G %d - new dir %f %f %f\n", ...); // new direction

  if (i == 3) // stop infinite loop
  {
    printf("G %d - itr max - ndir %f %f %f\n", ...);
    break;
  }
}

RT_PROGRAM void miss()
{
  printf("Miss\n");
  lightPrd.done = 1;
}

Solved. That was caused by light source geometry that didn’t have a hit program for given ray type.