Crash due to cross-DLL deallocation of std::string from static V8 library (CRT/heap ownership mismatch)

[Pradish]

we are seeing a Crash due to cross-DLL deallocation of std::string from static V8 library (CRT/heap ownership mismatch)

But this issue was never seen in earlier versions. we have not changed our code since many years.

is our assumption correct ? or is there anything changed in the latest version that we have take care of in our code.

Environment

OS: Windows 11

CPU architecture: x64

Compiler: clang-cl

MSVC toolchain: Visual Studio 2022 (v143)

V8 version / commit: 14.3.127.17

Build system: GN + Ninja

Build type: Static library (v8_monolith.lib)

 

args.gn:
is_component_build = false

is_debug = false

target_cpu = "x64"

use_custom_libcxx = false

v8_monolithic = true

v8_use_external_startup_data = false

is_clang = false

clang_use_chrome_plugins = false

treat_warnings_as_errors = false

v8_enable_test_features=false

v8_enable_fast_torque = false

v8_enable_sandbox = false

v8_enable_pointer_compression = false

v8_enable_backtrace = false

v8_enable_disassembler = false

v8_enable_object_print = false

v8_enable_verify_heap = false

v8_enable_slow_dchecks = false

v8_enable_gdbjit = false

v8_enable_i18n_support = true

v8_monolithic_for_shared_library = true

v8_static_library = true

icu_use_data_file = false

v8_enable_temporal_support = false

use_sysroot = false

symbol_level = 0

strip_debug_info=true

dcheck_always_on = false

 

Application:

We use V8 to execute JavaScript, and on Windows the V8 library is statically linked into our own DLL.
The application was working correctly up to version 14.1.146.11.
we were originally using V8 as a shared dll up to version  13.0.x, but later we had to switch to using the static V8 library, since shared DLL builds are not officially supported by V8 and we also migrated from MSVC to clang-cl.

 

As part of addressing security issues, we upgraded V8 to 14.3.127.17. After this upgrade, we are seeing frequent crashes inside our DLL, and many of the crash stacks point to operations involving std::basic_string.

 

 

Location:
    _CONSTEXPR20 ~basic_string() noexcept {

        _Tidy_deallocate();  //crashes here

#if _ITERATOR_DEBUG_LEVEL != 0

        auto&& _Alproxy          = _GET_PROXY_ALLOCATOR(_Alty, _Getal());

        const auto _To_delete    = _Mypair._Myval2._Myproxy;

        _Mypair._Myval2._Myproxy = nullptr;

        _Delete_plain_internal(_Alproxy, _To_delete);

#endif // _ITERATOR_DEBUG_LEVEL != 0

    }

 any inputs or pointers will be of great help.

Thank you for looking into this.

regards
Pradish

[Ben Noordhuis]

Crashes in _Tidy_deallocate, assuming they're not ordinary memory
corruption bugs in your application, suggests different parts of your
program have been linked to different versions of the standard C++
library. Check that V8 and your application are built with the same
compiler and linker flags.

[Pradish]

Thanks Ben for looking into this.

In my earlier email, I mistakenly mentioned is_clang = false; that was a typo. V8 is actually built with is_clang = true and as a static library, and the DLL that links to this static library is also built using clang-cl in Visual Studio 2022. Most importantly, this setup was working correctly up to version 14.1.146.11.

We started encountering crashes only after upgrading V8 to 14.2.xxx.xx. There were no changes on our side, so the issue appears to have been introduced with the V8 upgrade.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHQurc8iLXwSeX2na3tXt8wbcgv_txeiUHpZKM_3FKdL3GaYuw%40mail.gmail.com.