Crash on high resolution & Apple M1

[fluidray]

Using OIDN 2.3.1, OIDN crashes when committing the filter for a high resolution image (the following stack trace is for resolution 3456x1828). I'm including the C++ portion as well, but it's the standard setup using the albedo and normal images. Note that the same filter is used previously at lower resolution, then re-committed using the full resolution image. The crash happens every time the full resolution is image is used, either when committing the HDR filter or the Albedo filter.

Thread 65 Crashed:
0 Chromium Embedded Framework 0x12a390db8 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1329956
1 Chromium Embedded Framework 0x12a390db8 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1329956
2 Chromium Embedded Framework 0x12a390dd0 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1329980
3 Chromium Embedded Framework 0x12a390dec fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1330008
4 Chromium Embedded Framework 0x12a394adc fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1345608
5 Chromium Embedded Framework 0x12a3934f0 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1339996
6 Chromium Embedded Framework 0x12a392a7c fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1337320
7 Chromium Embedded Framework 0x12a39c3d8 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1376580
8 Chromium Embedded Framework 0x12a09a830 ChromeAppModeStart_v7 + 3938164
9 Chromium Embedded Framework 0x12a3a2c70 fontations_ffi$cxxbridge1$BridgeBitmapGlyph$operator$sizeof + 1403356
10 libsystem_malloc.dylib 0x1814e3e70 _malloc_zone_memalign + 316
11 libsystem_malloc.dylib 0x1814e454c _posix_memalign + 52
12 libOpenImageDenoise_core.dylib 0x34cd5a95c oidn::alignedMalloc(unsigned long, unsigned long) + 40
13 libOpenImageDenoise_core.dylib 0x34cd71de8 oidn::USMHeap::realloc(unsigned long) + 112
14 libOpenImageDenoise_core.dylib 0x34cd5ace4 oidn::ScratchArenaManager::attach(oidn::ScratchArena*) + 120
15 libOpenImageDenoise_core.dylib 0x34cd5af04 oidn::ScratchArena::ScratchArena(oidn::ScratchArenaManager*, unsigned long, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator> const&) + 100
16 libOpenImageDenoise_core.dylib 0x34cd774e0 oidn::Subdevice::newScratchArena(unsigned long, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator> const&) + 128
17 libOpenImageDenoise_core.dylib 0x34cd7fc84 oidn::UNetFilter::buildModel(unsigned long) + 1080
18 libOpenImageDenoise_core.dylib 0x34cd7e990 oidn::UNetFilter::init() + 1212
19 libOpenImageDenoise_core.dylib 0x34cd664ec oidn::Device::execute(std::__1::function<void ()>&&, oidn::SyncMode) + 40
20 libOpenImageDenoise_core.dylib 0x34cd7e2b4 oidn::UNetFilter::commit() + 236
21 libOpenImageDenoise.dylib 0x113232a04 oidnCommitFilter + 100
22 AmbientOcclusionEx_202400_osx_x64_4_0_1.bundle 0x3493222b0 oidn::FilterRef::commit() + 28 (oidn.hpp:507)
23 AmbientOcclusionEx_202400_osx_x64_4_0_1.bundle 0x349351084 pg_kernel_t::flush_films(bool, float, std::

m_oidn_filter.setImage("color", merged_image, oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
        m_oidn_filter.setImage("albedo", &m_albedo_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
        m_oidn_filter.setImage("normal", &m_normal_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
        m_oidn_filter.setImage("output", output_image, oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
        m_oidn_filter.set("hdr", true);
        m_oidn_filter.set("cleanAux", m_is_full_res);        
        m_oidn_filter.set("quality", m_is_full_res ? oidn::Quality::High : oidn::Quality::Fast);

        m_oidn_filter.setProgressMonitorFunction(&pg_kernel_t::filter_progress_func, (void*)(lock_request));
---> CRASHES EITHER HERE -->        m_oidn_filter.commit();

        if (m_is_full_res) {
            m_oidn_albedo_filter.setImage("albedo", &m_albedo_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
            m_oidn_albedo_filter.setImage("output", &m_albedo_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
            m_oidn_albedo_filter.setProgressMonitorFunction(&pg_kernel_t::filter_progress_func, (void*)(lock_request));
 ---> OR HERE -->            m_oidn_albedo_filter.commit();

            m_oidn_albedo_filter.execute();

            if (lock_request && *lock_request > 0) return;

            m_oidn_normal_filter.setImage("normal", &m_normal_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
            m_oidn_normal_filter.setImage("output", &m_normal_image.front(), oidn::Format::Float3, m_film_size.x, m_film_size.y, 0, sizeof(col4f));
            m_oidn_normal_filter.setProgressMonitorFunction(&pg_kernel_t::filter_progress_func, (void*)(lock_request));
            m_oidn_normal_filter.commit();

            m_oidn_normal_filter.execute();
            
            if (lock_request && *lock_request > 0) return;
        }

        m_oidn_filter.execute();

[atafra]

Could you please provide some more details about your system? Is it macOS? What architecture? Are you using CPU device or GPU device (if yes, which one)? Are you using an official binary or did you build it yourself? Did you try to reproduce the issue on a different machine or OS? The stack trace begins with a lot of references to Chromium. What does this mean exactly? The first call that I recognize is _posix_memalign, which suggests that the crash happens when allocating memory but I'm confused about the Chromium part. Did you check that you're not running out of memory?

Thanks!

[fluidray]

System: OSX 15.3.2 Apple M1 32Gb
The app crashing is SketchUp 2025 running natively on arm64.
I'm using the OIDN CPU device inside a rendering plugin for SketchUp, called AmbientOcclusion.
OIDN was built from source.
I think the Chromium part is due to SketchUp running CrashPad, which is part of the Chromium framework.
The memory used by SketchUp right before the crash is 2.75GB.
I tested on windows and the crash doesn't occur.

[atafra]

Thanks! I'm not sure what could be the issue. The crash seems to happen inside _posix_memalign, which shouldn't crash even if OIDN would pass invalid parameters. Could you perhaps try to obtain what are these parameters when the crash happens and what kind of crash is it exactly? Otherwise, I would need some kind of reproducer that I could try locally. In general, the scenario you mentioned (re-committing a filter with a higher resolution image after committing with a smaller one) is being tested in oidnTest. Did you try to commit initially with the same high resolution, without re-committing?

[fluidray]

This is the information about the crash type:

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000012874cdb8

Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5

I just tried to deinoise the full resolution right from the start without recommitting, still crashes.

I can provide the SketchUp extension that is crashing, you would have to install it on SketchUp 2025 on M1. I can package the extension with OIDN built in Debug configuration.

Edit:

If you don't need OIDN build in debug config, you can download the extension directly from here:

https://www.fluidinteractive.com/products/sketchup-extensions/ambientocclusion/

To reproduce, install it in SketchUp 2025.

1. In a new scene, go to Extensions -> AmbientOcclusion Ex -> Render Viewport.
2. Once the rendering has started, right-click on the viewport then select Resolution -> Twice as viewport.
3. Wait a few seconds for the renderer to reach the full resolution, and boom

[atafra]

Thanks! I'll give it a try. I'll try to replace the OIDN build with my own. Did you try other high resolutions too? It would be interesting to find out what is the largest resolution which still works without crashing.

[fluidray]

I'm going to see if I can find the exact resolution past which it crashes.

Please use the following source for OIDN, we changed the names of the shared libs in order to avoid conflicts with other extensions:

https://www.fluidinteractive.com/tmp/oidn-2.3.1.7z

And those are the CMake flags we used to build it: -DOIDN_ZIP_MODE=ON -DOIDN_FILTER_RTLIGHTMAP=OFF

[fluidray]

Tried a few resolutions, 1280x1232 never crashes, but 1280x1233 crashes every time

[atafra]

I can reproduce the issue but I'm confused about what's happening. The crash is happening somewhere inside Chromium Embedded Framework, which I'm not familiar with. If I look at the backtrace in LLDB, there's only one frame with Chromium Embedded Framework, unlike in your case. But even in your original report I don't understand how is Chrome Embedded Framework called from _posix_memalign. I'm not sure how to proceed with debugging this.

[atafra]

What's strange is that outside SketchUp/FluidRay there are no issues with such high resolutions. Is this a regression or OIDN always had this issue?

On off-topic question: why do you need to modify the OIDN source to rename the shared libs? The OIDN_LIBRARY_NAME CMake variable should do exactly that.

[fluidray]

Is it possible that at some point in the stack trace the heap is being corrupted and the crash just happens later down the stack in the Chromium framework? I'm not an expert on this, but are there any tools that allow to check if the stack has been corrupted?

[atafra]

I'm not an expert in this either unfortunately. But what's certain is that the crash is happening inside Chromium Embedded Framework which OIDN isn't calling. It's possible that OIDN does something wrong which makes some other thread to crash but it could be caused by something else too. It might be just a coincidence that the crash is triggered only when calling OIDN commit because that does some memory reallocation, and the heap might be already corrupted at that point.

A minimal reproducer would be very useful in this case, if possible.

[fluidray]

Everything used to work fine up to SketchUp 2024 and it works fine on FluidRay as well, both Windows and Mac.
The crash only happens on SketchUp 2025 on Apple silicon.
I haven't seen OIDN_LIBRARY_NAME before, has it been added recently or has it always been there? Does it allow to avoid having the library version in the name?

For a minimal reproducer, you would need the C++ source code of a minimal SketchUp extension that crashes?

[atafra]

I think at this point we cannot determine for sure that OIDN is indeed causing the issue. For a minimal reproducer, ideally the issue should be possible to be triggered outside SketchUp. A tool like Valgrind could help with the detection of memory issues like heap corruption.

OIDN_LIBRARY_NAME was added in v2.3.0 but it allows to change only the name of the library (OpenImageDenoise). It doesn't allow turning off the version in the name.

[fluidray]

Ok, I'll try to come up with a minimal example that reproduces the crash. I suspect that the crash will only happen inside SketchUp.

[fluidray]

I put together a simple reproducer, you can look at test.h to see the OIDN code.

https://www.fluidinteractive.com/tmp/oidntest.7z

The test includes both a standalone version and the version embedded in SketchUp. As expected, the standalone version doesn't crash and the SketchUp version does crash.

The package includes all the required libraries. To test in SketchUp, just use cmake to install, it will take care of copying everthing in the appropriate SketchUp plugin location.
To run the test inside SketchUp, go to Extensions->oidntest->Run Test