I just updated to Optix 6.5.0 and am getting odd behavior. Whenever I enable all exceptions, the program crashes during the first call to rtContextLaunch*D. Using rtContextSetUsageReportCallback shows that it is somewhere in the middle of compiling the device programs for my particular driver version when this happens. There is no message printed to the console, but the exit code is 0xFFFFFFFFC0000005. I am enabling exceptions with this code:
Environment: Windows 10, OptiX 6.5.0, display driver 436.15, CUDA driver 10.1.0, GeForce GTX 1080 Ti and RTX 8000 installed (using only one at a time).
Will you see if you can reproduce this on one of the OptiX SDK samples? I tried using samples_sdk/optixPathTracer, adding context->setExceptionEnabled(RT_EXCEPTION_ALL, true) in the createContext() call, immediately after Context::create(). That doesn’t crash on me yet, so I’d like to figure out how to repro this.
If the program crashed, then the exit code provided is a generic Windows system exit code. Searching I found that 0xFFFFFFFFC0000005 means EXCEPTION_ACCESS_VIOLATION via Winbase.h, so it doesn’t give us much information.
Thanks for looking into this. I did some digging, and it turns out that only enabling RT_EXCEPTION_BUFFER_ID_INVALID is a problem. The rest of the exception testing doesn’t seem to cause a problem with my program. Note that there aren’t any invalid buffers (or at least, there weren’t under OptiX 6.0, and the program runs smoothly if I don’t test for them), it’s just the fact that I’m testing for invalid buffers that causes the crash.
Perhaps there is something up with my shaders that is causing the error. I’m sending a reproducer to the help email, just enabling RT_EXCEPTION_BUFFER_ID_INVALID. For me it crashes at rtContextLaunch2D (which is of course the end of the trace file). Hopefully this will let you observe the same behavior.