Closed tomas16 closed 8 months ago
I figured out the problem: when scene
goes out of scope in the python function hit_test
, the underlying C++ objects are cleaned up. However, execution of the kernel is triggered by the np.asarray()
call in main
, so by the time the kernel runs the memory for scene has been freed.
There are 2 workarounds that I've tested successfully:
np.asarray
call inside the hit_test
function, so the last line becomes return np.asarray(was_hit)
scene
object in main
and pass it in as an argument to hit_test
I'm not familiar enough with the code to quickly fix this myself. However if kernels keep a reference to their dependencies, it may be a simple matter of incrementing the refcount of the scene object there and decrementing it in the kernel's destructor.
Hi @tomas16,
I was able to also get heap-use-after-free
errors after enabling Address Sanitizer. Thanks for the reproducer!
There are 2 workarounds that I've tested successfully:
- Put the np.asarray call inside the hit_test function, so the last line becomes return np.asarray(was_hit)
- Create the scene object in main and pass it in as an argument to hit_test
That makes sense. I think similarly just adding dr.eval(was_hit)
prior to returning from hit_test
would also be an alternate workaround. But this is all just masking what I think is a legitimate bug. I think I know what's going on but just want to investigate a bit further to confirm my suspicions.
This issue replaces #204.
Save the following code as
segfault.py
:Run it with AddressSanitizer:
It looks like mitsuba is calling embree for intersection testing while the whole embree acceleration structure has already been deallocated by a different thread. Note the heap-use-after-free doesn't always occur on the exact same line, which doesn't matter as the real issue seems to be related to erroneously decrementing the refcount of some (all?) variables.
For smaller wavefront sizes, the heap-use-after-free doesn't always occur.
If you run this without AddressSanitizer, it's likely you will get the correct result. However this is all derived from issue #204, where the behavior is one of (segfault, correct result, incorrect result). In all 3 cases though, AddressSanitizer catches this heap-use-after-free. So while this issue doesn't cause this toy example to fail, it does cause trouble in real code.
Versions