Yet another test confirms my assumptions. I performed the exact same tests on a Debian 12 host (libicu 72) and no issues at all. I will try to figure out if it could be fixed some way.
Thanks for your support. I really appreciated it. Angelo Il giorno giovedì 7 marzo 2024 alle 13:26:51 UTC+1 in...@bnoordhuis.nl ha scritto: > On Thu, Mar 7, 2024 at 12:16 PM Angelo Dell'Aera > <angelo....@gmail.com> 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 v8-dev@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/38371bfa-985a-4f8b-8bba-cb9200218ea9n%40googlegroups.com.
