rerun [CPP] ASAN - error with ViewCoordinates

running with an address sanitizer is raising an error on ViewCoordinates archetypes

To Reproduce Steps to reproduce the behavior:

// Change the view coordinates for the scene.

#include <rerun.hpp>

int main() {
    const auto rec = rerun::RecordingStream("rerun_example_view_coordinates");
    rec.spawn().exit_on_failure();

    rec.log_static("world", rerun::ViewCoordinates::RIGHT_HAND_Z_UP); // Set an up-axis
}

Expected behavior It should compile and run fine

Backtrace

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x61f463a in posix_memalign    #1 0xd1b9ab9 in arrow::(anonymous namespace)::SystemAllocator::AllocateAligned(long, long, unsigned char**) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:321:9
    #2 0xd1b0e87 in arrow::BaseMemoryPoolImpl<arrow::(anonymous namespace)::SystemAllocator>::Allocate(long, long, unsigned char**) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:463:5
    #3 0xd1b8725 in arrow::PoolBuffer::Reserve(long) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:865:9
    #4 0xd1b7761 in arrow::PoolBuffer::Resize(long, bool) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:889:7
    #5 0xd1b08e3 in arrow::Result<std::unique_ptr<arrow::ResizableBuffer, std::default_delete<arrow::ResizableBuffer>>> arrow::(anonymous namespace)::ResizePoolBuffer<std::unique_ptr<arrow::ResizableBuffer, std::default_delete<arrow::ResizableBuffer>>, std::unique_ptr<arrow::PoolBuffer, std::default_delete<arrow::PoolBuffer>>>(std::unique_ptr<arrow::PoolBuffer, std::default_delete<arrow::PoolBuffer>>&&, long) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:936:3
    #6 0xd1b08e3 in arrow::AllocateResizableBuffer(long, long, arrow::MemoryPool*) third-party/apache-arrow/default/cpp/src/arrow/memory_pool.cc:962:10
    #7 0x63b24b6 in arrow::BufferBuilder::Resize(long, bool) third-party/apache-arrow/default/cpp/src/arrow/buffer_builder.h:78:7
    #8 0x9e41a28 in arrow::TypedBufferBuilder<unsigned char, void>::Resize(long, bool) third-party/apache-arrow/default/cpp/src/arrow/buffer_builder.h:287:27
    #9 0x9e41a28 in arrow::NumericBuilder<arrow::UInt8Type>::Resize(long) third-party/apache-arrow/default/cpp/src/arrow/array/builder_primitive.h:152:5
    #10 0x63a15f0 in arrow::ArrayBuilder::Reserve(long) third-party/apache-arrow/default/cpp/src/arrow/array/builder_base.h:145:12
    #11 0x63b6670 in arrow::NumericBuilder<arrow::UInt8Type>::AppendValues(unsigned char const*, long, unsigned char const*) third-party/apache-arrow/default/cpp/src/arrow/array/builder_primitive.h:170:5
    #12 0x63b5fcb in rerun::Loggable<rerun::datatypes::ViewCoordinates>::fill_arrow_array_builder(arrow::FixedSizeListBuilder*, rerun::datatypes::ViewCoordinates const*, unsigned long) third-party/rerun_cpp_sdk/src/rerun/datatypes/view_coordinates.cpp:56:9
    #13 0x63b54ca in rerun::Loggable<rerun::datatypes::ViewCoordinates>::to_arrow(rerun::datatypes::ViewCoordinates const*, unsigned long) third-party/rerun_cpp_sdk/src/rerun/datatypes/view_coordinates.cpp:27:13
    #14 0x6392027 in rerun::Loggable<rerun::components::ViewCoordinates>::to_arrow(rerun::components::ViewCoordinates const*, unsigned long) third-party/rerun_cpp_sdk/src/rerun/archetypes/../components/view_coordinates.hpp
    #15 0x63919ef in rerun::Result<rerun::ComponentBatch> rerun::ComponentBatch::from_loggable<rerun::components::ViewCoordinates>(rerun::Collection<rerun::components::ViewCoordinates> const&, rerun::ComponentDescriptor const&) third-party/rerun_cpp_sdk/src/rerun/component_batch.hpp:59:26
    #16 0x6392f68 in rerun::Result<rerun::ComponentBatch> rerun::ComponentBatch::from_loggable<rerun::components::ViewCoordinates>(rerun::components::ViewCoordinates const&, rerun::ComponentDescriptor const&) third-party/rerun_cpp_sdk/src/rerun/component_batch.hpp:75:20
    #17 0x6392f68 in rerun::archetypes::ViewCoordinates::ViewCoordinates(rerun::components::ViewCoordinates) third-party/rerun_cpp_sdk/src/rerun/archetypes/view_coordinates.hpp:331:19
    #18 0x6393253 in __cxx_global_var_init third-party/rerun_cpp_sdk/src/rerun/archetypes/view_coordinates_ext.cpp:275:9
    #19 0x6393253 in _GLOBAL__sub_I_view_coordinates_ext.cpp third-party/rerun_cpp_sdk/src/rerun/archetypes/view_coordinates_ext.cpp
    #20 0x7fc44142c793 in call_init /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../csu/libc-start.c:145:3
    #21 0x7fc44142c793 in __libc_start_main@GLIBC_2.2.5 /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../csu/libc-start.c:379:5
    #22 0x6143360 in _start /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../sysdeps/x86_64/start.S:116

SUMMARY: AddressSanitizer: 3840 byte(s) leaked in 60 allocation(s).

Additional context

Replacing by

rec.log_static("world", rerun::ViewCoordinates(rerun::components::ViewCoordinates::RIGHT_HAND_X_UP));

is making the program work and run as expected without any memory leak... Does rerun have made a mistake between the archetype and the component for the ViewCoordinates archetypes for the const definitions?

cc @Wumpf

Apr 05 '25 16:04 SeaOtocinclus

Wouldn't be the first false positive we get from the address sanitizer, but let's not prematurely dismiss it. I don't think ViewCoordinates is particularly special in its (generated) implenetation of fill_arrow_array_builder, but who knows maybe something isn't quite right there. Could also be that this goes away with an libarrow update.

Apr 05 '25 17:04 Wumpf

ASAN sometimes triggers false positives when using memory-pool backed objects. Is there a function to discard arrow memory pool?

Apr 07 '25 20:04 alokpr

We use default_memory_pool everywhere so far, not sure if it's possible (or safe) to shut it down entirely.

Apr 08 '25 13:04 Wumpf

@Wumpf We also found out that using rerun::Clear::RECURSIVE is also leading to this issue. So now I'm weighting toward, if you use a static variable you will have an issue, but if you use a created variable, you would be fine (such as rerun::Clear(rerun::Clear::RECURSIVE))

Apr 09 '25 20:04 SeaOtocinclus

The rust migration guide describes eager archetype serialization - "serialization of archetype components now occurs at time of archetype instantiation rather than logging". In both of these failing examples, we are using archetypes (rerun::archetypes::ViewCoordinates::RUB or rerun::archteypes::Clear::RECURSIVE) stored as constants. Could this be interfering with the new serialization approach? The Rust API seems to now use methods instead of constants (e.g., ViewCoordinates::RUB()).

The mitigations that make ASAN happy use the lower component-level constants (rerun::components::ViewCoordinates::RUB or rerun::components::Clear::ClearIsRecursive), which are perhaps not impacted by changes to archetype serialization.

Apr 09 '25 20:04 ewhitmire