On Thu, Mar 7, 2024 at 12:16 PM Angelo Dell'Aera <[email protected]> wrote: > > I collected a gdb backtrace and it shows something which is potentially > interesting > > (gdb) info stack > #0 0x00007ffff4d72ae6 in v8::base::OS::Abort() () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #1 0x00007ffff4d6af7c in v8::base::FatalOOM(v8::base::OOMType, char const*) > () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #2 0x00007ffff440c58c in > v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char > const*, v8::OOMDetails const&) () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #3 0x00007ffff46f998a in v8::internal::(anonymous > namespace)::DateTimePatternGeneratorCache::CreateGenerator(v8::internal::Isolate*, > icu_73::Locale const&) () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #4 0x00007ffff46f7e06 in > v8::internal::JSDateTimeFormat::CreateDateTimeFormat(v8::internal::Isolate*, > v8::internal::Handle<v8::internal::Map>, > v8::internal::Handle<v8::internal::Object>, > v8::internal::Handle<v8::internal::Object>, > v8::internal::JSDateTimeFormat::RequiredOption, > v8::internal::JSDateTimeFormat::DefaultsOption, char const*) () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #5 0x00007ffff46f8efa in > v8::internal::JSDateTimeFormat::New(v8::internal::Isolate*, > v8::internal::Handle<v8::internal::Map>, > v8::internal::Handle<v8::internal::Object>, > v8::internal::Handle<v8::internal::Object>, char const*) () > from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #6 0x00007ffff4dafd4e in > v8::internal::Builtin_DateTimeFormatConstructor(int, unsigned long*, > v8::internal::Isolate*) () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #7 0x00007ffff4c335b6 in Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit () > from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #8 0x00007ffff4b9f3fc in > Builtins_InterpreterPushArgsThenFastConstructFunction () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #9 0x00002136d010c8f9 in ?? () > #10 0x00002136d010c8f9 in ?? () > #11 0x0000000500000000 in ?? () > #12 0x000027e541540c19 in ?? () > #13 0x000027e541540c19 in ?? () > #14 0x000027e541540c19 in ?? () > #15 0x00001bbc90f9d349 in ?? () > #16 0x0000000000000030 in ?? () > #17 0x00007fffffff7940 in ?? () > #18 0x00007ffff4d2736c in Builtins_ConstructHandler () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > #19 0x0000207ba8729fe1 in ?? () > #20 0x00001bbc90fb50b9 in ?? () > #21 0x000027e541540061 in ?? () > #22 0xfffffffffffffffe in ?? () > #23 0x00007ffff4d1b0a0 in Builtins_SetNamedPropertyHandler () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > As we can see from #3 > > #3 0x00007ffff46f998a in v8::internal::(anonymous > namespace)::DateTimePatternGeneratorCache::CreateGenerator(v8::internal::Isolate*, > icu_73::Locale const&) () from > /home/angelo/.local/lib/python3.9/site-packages/_STPyV8.cpython-39-x86_64-linux-gnu.so > > the CreatePattern second parameter type is supposed to be icu_73::Local. > > As I mentioned in a previous email, Debian 11 is the only environment that > allows me to reproduce the issue reliably while the > issue is not present in all the other environments. So I checked the system > libicu version and realized that libicu 67 is installed > on Debian 11 and libicu 74 is installed on all the other systems. > > During the build workflow, I statically link libv8_monolith to STPyV8 so I > don't really expect but if V8 ends up using the system > libicu (because I do not link statically the third party library too? is it > really required?) and that libicu 73 API is not compatible > with the libicu 67 one that could explain what I am observing. > > Angelo
I think you've found the cause. (I had a hunch it was conflicting symbols/libraries, hence my suggestion of turning on use_custom_libcxx.) It's possible something else also loads (or exports a copy of) ICU and makes you end up with the wrong version when the dynamic linker does runtime linking. -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAHQurc-%2BA2jzWT7acsdHye2XtjA8%3DdKX%2BtNr8WEkwL2kYG3vSQ%40mail.gmail.com.
