search

RenderKit / ospray

An Open, Scalable, Portable, Ray Tracing Based Rendering Engine for High-Fidelity Visualization
http://ospray.org
Apache License 2.0
982 stars 178 forks source link

Debugging segfault on VolumetricModel commit() #499

Closed paulmelis closed 2 years ago

paulmelis commented 2 years ago

I'm having a hard time finding the cause of a segfault when committing a VolumetricModel. This happens during a second render call in blospray, where the first render succeeds, producing a good image. Some of the scene elements then get updated, such as a new TransferFunction and new VolumetricModel (but reusing the existing structuredRegular Volume). The transfer function is nothing special, just 128 entries of vec3f for color and 128 floats for opacity. The volume small as well, 128^3 floats. Nothing of interest is shown with debug log output.

Unfortunately I've been unable to create a small standalone sample that reproduces the error outside of blospray. So I was wondering if the stack trace might give some clues to what is going on, or where to look further? This happens with 2.7.0 and also a recent git version. 

Thread 1 "blserver" received signal SIGSEGV, Segmentation fault.
0x00007fffee2a60d1 in vklNewIntervalIteratorContext () from /home/melis/software/ospray-superbuild-git/lib/libopenvkl.so.1
(gdb) bt
#0  0x00007fffee2a60d1 in vklNewIntervalIteratorContext () from /home/melis/software/ospray-superbuild-git/lib/libopenvkl.so.1
#1  0x00007ffff0df7179 in ospray::VolumetricModel::commit (this=0x555556ed4fe0) at /home/melis/c/ospray-git/ospray/volume/VolumetricModel.cpp:56
#2  0x00007ffff0da0a8d in ospray::api::ISPCDevice::commit (this=<optimized out>, _object=0x555556ed4fe0)
    at /home/melis/c/ospray-git/ospray/api/ISPCDevice.cpp:416
#3  0x00007ffff7eb349f in ospCommit (_object=0x555556ed4fe0) at /home/melis/c/ospray-git/ospray/api/API.cpp:557
#4  0x0000555555591eb5 in ospray::cpp::ManagedObject<osp::VolumetricModel*, (OSPDataType)134217843>::commit (this=0x7fffffffd818)
    at /home/melis/software/ospray-superbuild-git/include/ospray/ospray_cpp/ManagedObject.h:172
#5  0x000055555556f46d in update_volume_object (update=..., volume_settings=...) at /home/melis/concepts/blender-ospray-engine/server/main.cpp:1556
#6  0x00005555555758e6 in handle_update_object (sock=0x555556edee80) at /home/melis/concepts/blender-ospray-engine/server/main.cpp:2182
#7  0x000055555557cdab in handle_client_message (sock=0x555556edee80, client_message=..., connection_done=@0x7fffffffdb77: false)
    at /home/melis/concepts/blender-ospray-engine/server/main.cpp:3075
#8  0x000055555557d97f in handle_connection (sock=0x555556edee80) at /home/melis/concepts/blender-ospray-engine/server/main.cpp:3324
#9  0x000055555557f2bf in main (argc=1, argv=0x7fffffffe278) at /home/melis/concepts/blender-ospray-engine/server/main.cpp:3673

This is based on a debug superbuild, although it seems the CMAKE_BUILD_TYPE=Debug flag doesn't propagate to the non-OSPRay dependencies. Any way to enable a debug build for all components when using the superbuild?

johguenther commented 2 years ago

The crash you are seeing could actually be related to d7824bb7d14acc259e7e33b3e43f2fc7762902b5 (a fix coming in patch release v2.7.1 in a few days): are all opacity values zero (for the set valueRange)?

If not, there is DEPENDENCIES_BUILD_TYPE (which will be propagated as CMAKE_BUILD_TYPE for dependencies like Open VKL) , so set it to Debug (we use that in CI to build everything with Debug). And consider to enable some BUILD_*_FROM_SOURCE if symbols from those are needed.

paulmelis commented 2 years ago

Making some headway on this, it appears to be one ospRelease() too many on the Volume on my side. But I really need to clean up the combination of C and C++ API use involved to be sure.

johguenther commented 2 years ago

Any update on this? Can we help, or can the issue be closed?

paulmelis commented 2 years ago

I guess it can be closed. I'm still in the process of refactoring my code in order to rule out issues on my side. Will reopen if needed.