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
Il giorno giovedì 7 marzo 2024 alle 09:10:04 UTC+1 in...@bnoordhuis.nl ha
scritto:
> On Wed, Mar 6, 2024 at 4:22 PM Angelo Dell'Aera
> <angelo....@gmail.com> wrote:
> >
> >
> >
> > Did you also update ICU? That error message indicates V8 couldn't
> > create a icu::DateTimePatternGenerator instance.
> >
> >
> > The Github Actions workflow I use to build STPyV8 automatically fetches
> the V8 repository,
> > perfoms a checkout of the V8 version I specify in my settings, syncs the
> code with gclient
> > sync and builds it using the following gn args
> >
> > gn_args = {
> > "dcheck_always_on": "false",
> > "is_component_build": "false",
> > "is_debug": "true" if os.environ.get("STPYV8_DEBUG") else "false",
> > "treat_warnings_as_errors": "false",
> > "use_custom_libcxx": "false",
> > "v8_deprecation_warnings": "true",
> > "v8_enable_disassembler": "false",
> > "v8_enable_i18n_support": "true",
> > "v8_enable_pointer_compression": "false",
> > "v8_enable_31bit_smis_on_64bit_arch": "false",
> > "v8_imminent_deprecation_warnings": "true",
> > "v8_monolithic": "true",
> > "v8_use_external_startup_data": "false",
> > }
> >
> > No manual ICU update then.
> >
> >
> > Try building V8 with debug checks enabled, that should give you a
> > better idea of the root cause.
> >
> >
> > I tried but all I got is this error
> >
> > *** stack smashing detected ***: terminated
> >
> > I perfomed an additional test rebuilding setting v8_enable_i18n_support
> to false and the
> > issue disappeared.
> >
> > Please be aware that I am able to reproduce the reported issue very
> reliably on Debian 11
> > but everything works fine if the same code runs on Gentoo Linux, macOS
> and Windows.
> >
> > Regards,
> > Angelo
>
> I'd try to narrow down why that debug build crashes the way it does.
> What does the backtrace look like in gdb? What happens in a debug +
> ASAN or MSAN build?
>
> Another thing you could try for debugging is to set
> use_custom_libcxx=true and see if that makes things worse or better.
>
--
--
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/09d065b7-ebe8-4947-a708-51e5350ba667n%40googlegroups.com.
