Crash in rtBufferCreate() using Ubuntu 16.04

I get a crash when running any optix SDK programs on my Gigabyte P57 laptop running Ubuntu 16.04.3 LTS. For instance:

/data/Code/build_optix_sdk/bin$ ./optixHello
pure virtual method called
terminate called without an active exception
Aborted (core dumped)

Running inside gdb results in this stack trace:

#0 0x00007ffff4f71428 in __GI_raise (sig=sig@entry=6) at …/sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4f7302a in __GI_abort () at abort.c:89
#2 0x00007ffff6ac88e7 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#3 0x00007ffff6abea9a in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#4 0x00007ffff6abeac2 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#5 0x00007ffff6ac9792 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#6 0x00007ffff5f1492b in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#7 0x00007ffff5f14f67 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#8 0x00007ffff5f13e4a in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#9 0x00007ffff5ebf932 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#10 0x00007ffff5a87d7f in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#11 0x00007ffff5a92b43 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#12 0x00007ffff5a19ba1 in ?? () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#13 0x00007ffff59be676 in rtBufferCreate () from /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1
#14 0x0000000000405f76 in main (argc=1, argv=0x7fffffffde18) at /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/SDK/optixHello/optixHello.cpp:93

Line 93 of optixHello.cpp is:

    RT_CHECK_ERROR( rtBufferCreate( context, RT_BUFFER_OUTPUT, &buffer ) );

so the function rtBufferCreate() is crashing.

My driver version is 384.90. I set LD_LIBRARY_PATH=“/usr/lib/nvidia-384”. The output of optixDeviceQuery is:

OptiX 4.1.1
Number of Devices = 1

Device 0: GeForce GTX 1060
Compute Support: 6 1
Total Memory: 6367739904 bytes
Clock Rate: 1670500 kilohertz
Max. Threads per Block: 1024
SM Count: 10
Execution Timeout Enabled: 1
Max. HW Texture Count: 1048576
TCC driver enabled: 0
CUDA Device Ordinal: 0

Constructing a context…
Created with 1 device(s)
Supports 2147483647 simultaneous textures
Free memory:
Device 0: 5889589248 bytes

ldd returns; /data/Code/build_optix_sdk/bin$ ldd ./optixHello
linux-vdso.so.1 => (0x00007ffd1ac50000)
libsutil_sdk.so => /data/Code/build_optix_sdk/lib/libsutil_sdk.so (0x00007f6172528000)
liboptix.so.1 => /data/Code/NVIDIA-OptiX-SDK-4.1.1-linux64/lib64/liboptix.so.1 (0x00007f61702c9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f616ff47000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f616fd31000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f616f967000)
libglut.so.3 => /usr/lib/x86_64-linux-gnu/libglut.so.3 (0x00007f616f71f000)
libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f616f4b0000)
libGL.so.1 => /usr/lib/nvidia-384/libGL.so.1 (0x00007f616f20c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f616ef03000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f616ece6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f616eae2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6172802000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f616e7a8000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f616e598000)
libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f616e392000)
libGLX.so.0 => /usr/lib/nvidia-384/libGLX.so.0 (0x00007f616e162000)
libGLdispatch.so.0 => /usr/lib/nvidia-384/libGLdispatch.so.0 (0x00007f616de94000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f616dc72000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f616da60000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f616d85c000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f616d656000)

Does anyone have an idea what is wrong, or a way to diagnose the problem?

Hi Philip, this could be tough to diagnose remotely, but one thing to try is the optixConsole sample, which does not bring up a GUI window. If that works, then the problem is mostly likely related to the GL setup on your system.

If you get that far, the next thing I would try is to stop using LD_LIBRARY_PATH to point to the GL libraries from the driver, and instead install the driver libraries to the standard places, e.g., /usr/lib/x86_64-linux-gnu/libGL.so. This may require an uninstall/reinstall of the driver. Did you perhaps do a custom install to get them into the /usr/lib/nvidia-384 path?

Good luck with it.

Thanks for this, it is true that there is something non-standard in my install, and I should probably rebuild my OS at some point to clean it up. However the /usr/lib/nvidia-384 folder was created automatically by the “deb (local)” Cuda install option for Ubuntu. Anyway, a colleague and I narrowed down the problem using strace, and found a message towards the end of the strace log indicating permission denied for a file. It turned out that the .nv/ComputeCache folder was owned by root, and this was causing the problem. Removing this folder fixed the problem. I’m not sure how this would cause the “pure virtual method called” problem, but somehow it did.