Skip to content

several sanitizer issues across platforms #1557

@matthargett

Description

@matthargett

Describe the bug
there's a few memory-related bugs that GCC and LLVM sanitizers complain about. I'm filing this issue so I don't forget to circle back and try to resolve them.

To Reproduce
Steps to reproduce the behavior:

  1. build debug unit tests and run them on platform: cmake --build build --target UnitTests

Expected behavior
should be clean of sanitizer issues.

Screenshots

macOS (AddressSanitizer + UBSan, debug)

  /Users/matt/src/JsRuntimeHost/Core/Node-API/Include/Shared/napi/napi-inl.h:4504:17: runtime error: downcast of address
  0x60800004c420 which does not point to an object of type 'Babylon::Polyfills::Internal::URLSearchParams'
  0x60800004c420: note: object is of type 'Napi::ObjectWrap<Babylon::Polyfills::Internal::URLSearchParams>'
   01 00 00 00  90 1f 92 04 01 00 00 00  00 00 00 00 00 00 00 00
                ^~~~~~~~~~~~~~~~~~~~~~~
                vptr for 'Napi::ObjectWrap<Babylon::Polyfills::Internal::URLSearchParams>'
      #0  Napi::ObjectWrap<URLSearchParams>::ObjectWrap(...)
      #1  Babylon::Polyfills::Internal::URLSearchParams::URLSearchParams(...)
      #6  napi::ConstructorInfo::CallAsConstructor(...)
      #… (call stack continues into JavaScriptCore)

Same warning fires repeatedly while the JS polyfill tests run.

Linux (Ubuntu 24.04, ASan + UBSan)

  Direct leak of 4096 byte(s) in 1 object(s) allocated from:
      #0 0xffff93ee646c in malloc …
      #1 0xffff92d600c0 in JSContextGroupCreate (/usr/lib/aarch64-linux-gnu/libjavascriptcoregtk-4.1.so.0+0x1a00c0)
      #2 0xaaaac4d88108 in napi_open_handle_scope …/Core/Node-API/Source/js_native_api_javascriptcore.cc:626
      #3 0xaaaac4d9a0cc in napi_run_script …/Core/Node-API/Source/js_native_api_javascriptcore.cc:2576
      #…

  Direct leak of 64 byte(s) in 1 object(s) allocated from:
      #0 0xffff93ee646c in realloc …
      #1 0xffff91cb87d8 in __cxa_demangle …
      #2 0xffff9142b9a0 in __sanitizer::Symbolizer::Demangle …
      #3 0xffff9140d288 in HandleDynamicTypeCacheMiss …
      #4 0xffff9140d3b4 in __ubsan_handle_dynamic_type_cache_miss …
      #5 0xaaaac4b1e178 in Napi::ObjectWrap<URLSearchParams>::ObjectWrap …
      #…

  SUMMARY: AddressSanitizer: 640 byte(s) leaked in 10 allocation(s).

The test binary still exits 0, but ASan flags the leaks and UBSan reports the same URLSearchParams RTTI mismatch as macOS.

Android emulator (API 29, UBSan build)

  /Users/matt/src/JsRuntimeHost/Build/Android/Debug/5wz1p653/arm64-v8a/_deps/googletest-src/googletest/src/gtest.cc:5974:31
    runtime error: member access within address 0x0072fd02ac80 which does not
    point to an object of type 'testing::internal::UnitTestImpl'
    00 00 00 00  38 23 d0 a2 72 00 00 00  90 4e f3 a2 …
                  ^~~~~~~~~~~~~~~~~~~~~~~
                  vptr for 'testing::internal::UnitTestImpl'

  /Users/matt/src/JsRuntimeHost/Build/Android/Debug/5wz1p653/arm64-v8a/_deps/googletest-src/googletest/src/gtest.cc:3870:1
    runtime error: member access within address 0x0073926e8820 which does not
    point to an object of type 'testing::internal::TestEventRepeater'
    00 00 00 00  90 20 d0 a2 72 00 00 00  01 74 65 73 …
                  ^~~~~~~~~~~~~~~~~~~~~~~
                  vptr for 'testing::internal::TestEventRepeater'

These show up in logcat during connectedDebugAndroidTest when the sanitized build runs; tests still finish green but UB sanitizer make this noise on gtest teardown. Newer gtest could fix it.

Other

  • Platform: Android, macOS, Linux

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions