Build failure on Mac arm64 when creating snapshot blob

89 views
Skip to first unread message

Ronald Fenner

unread,
Dec 12, 2024, 10:22:38 AM12/12/24
to v8-dev
I was updating my version of v8 lib since in relation to my previous bug with cppgc was on a 12.4.254.15 and it was pointed out that there have been changes like the wrapper descriptor being removed and new functions to wrap/unwrap a cppgc instance added to v8:Object.
During the build process when it hits the snapshot creation it throws an error and prints the stack trace
[2123/2127] ACTION //:run_mksnapshot_default(//build/toolchain/mac:clang_arm64)
FAILED: gen/embedded.S snapshot_blob.bin
python3 ../../tools/run.py ./mksnapshot --turbo_instruction_scheduling --stress-turbo-late-spilling --target_os=mac --target_arch=arm64 --embedded_src gen/embedded.S --predictable --no-use-ic --embedded_variant Default --random-seed 314159265 --startup_blob snapshot_blob.bin --no-native-code-counters


#
# Fatal error in , line 0
# Check failed: 12 == (*__error()).
#
#
#
#FailureMessage Object: 0x16fd36658
==== C stack trace ===============================

    0   mksnapshot                          0x0000000100a2fa8c v8::base::debug::StackTrace::StackTrace() + 24
    1   mksnapshot                          0x0000000100a339a0 v8::platform::(anonymous namespace)::PrintStackTrace() + 24
    2   mksnapshot                          0x0000000100a26448 V8_Fatal(char const*, ...) + 356
    3   mksnapshot                          0x0000000100a2e2b0 v8::base::OS::SetPermissions(void*, unsigned long, v8::base::OS::MemoryPermission) + 284
    4   mksnapshot                          0x0000000100a205d0 v8::base::BoundedPageAllocator::SetPermissions(void*, unsigned long, v8::PageAllocator::Permission) + 32
    5   mksnapshot                          0x00000001001ff344 v8::internal::CodeRange::InitReservation(v8::PageAllocator*, unsigned long, bool) + 584
    6   mksnapshot                          0x0000000100317ba8 v8::internal::(anonymous namespace)::InitCodeRangeOnce(std::__1::unique_ptr<v8::internal::CodeRange, std::__1::default_delete<v8::internal::CodeRange>>*, v8::PageAllocator*, unsigned long, bool) + 128
    7   mksnapshot                          0x0000000100a2abb0 v8::base::CallOnceImpl(std::__1::atomic<unsigned char>*, std::__1::function<void ()>) + 68
    8   mksnapshot                          0x0000000100317ac8 v8::internal::IsolateGroup::EnsureCodeRange(unsigned long) + 136
    9   mksnapshot                          0x000000010026e990 v8::internal::Heap::SetUp(v8::internal::LocalHeap*) + 180
    10  mksnapshot                          0x00000001001d6724 v8::internal::Isolate::Init(v8::internal::SnapshotData*, v8::internal::SnapshotData*, v8::internal::SnapshotData*, bool) + 1684
    11  mksnapshot                          0x00000001001d6084 v8::internal::Isolate::InitWithoutSnapshot() + 28
    12  mksnapshot                          0x0000000100696418 v8::internal::SnapshotCreatorImpl::InitInternal(v8::StartupData const*) + 96
    13  mksnapshot                          0x00000001006967f4 v8::internal::SnapshotCreatorImpl::SnapshotCreatorImpl(v8::internal::Isolate*, v8::Isolate::CreateParams const&) + 276
    14  mksnapshot                          0x00000001000bad98 v8::SnapshotCreator::SnapshotCreator(v8::Isolate*, v8::Isolate::CreateParams const&) + 48
    15  mksnapshot                          0x00000001000afb2c main + 1392
    16  dyld                                0x000000018d51c274 start + 2840
Return code is -5

this is for the latest stable release of 13.1.201.16 that ships in the latest chromium version.

I'm assuming some flags have changed and may be causing the issue.
My build args are for debug
is_debug = true
is_component_build = false
v8_monolithic = false
v8_use_external_startup_data = true
v8_enable_backtrace = true
v8_enable_slow_dchecks = true
v8_optimized_debug = false
use_custom_libcxx = false
v8_static_library = true
v8_enable_pointer_compression_shared_cage = false
enable_iterator_debugging = true
v8_use_libm_trig_functions = false
icu_disable_thin_archive = true
v8_target_cpu = "arm64"
target_cpu = "arm64"

and release is
is_debug = false
is_component_build = false
v8_monolithic = false
v8_use_external_startup_data = true
dcheck_always_on = false
use_custom_libcxx = false
v8_static_library = true
v8_enable_pointer_compression_shared_cage = false
v8_use_libm_trig_functions = false
icu_disable_thin_archive = true
v8_target_cpu = "arm64"
target_cpu = "arm64"

This occurs in both build of it. I also tried 13.1.201.18 which gives the same error with a slightly more informative assert adding something like 13 != 12 

Clemens Backes

unread,
Dec 13, 2024, 6:14:17 AM12/13/24
to v8-...@googlegroups.com
We expect that if setting permissions on memory fails, it must be due to an out of memory situation (the ENOMEM error code is the integer 12).
What you get is EACCES (13). This is unexpected.

It's hard to tell why this fails from just that stack trace. You could help narrowing it down by running a bisection to figure out which change introduced this (see https://git-scm.com/docs/git-bisect).

--
--
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/15094b1c-60e6-47e9-8e24-0367293ee326n%40googlegroups.com.


--

Clemens Backes

Software Engineer

clem...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München


Geschäftsführer: Paul Manicle, Liana Sebastian   

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg


Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.


This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.


Ronald Fenner

unread,
Dec 14, 2024, 5:57:16 AM12/14/24
to v8-dev
I tracked it back to 12.5.97 tag but the commit that has code changes is 536571f811e9a51756b4b71f471dd3436b97a6bf.

Since it's been many months ago I'm wondering if this is some security change or bug in Mac OSX 15.x as thats what i'm building on. I just updated to 15.2 from 15.1.1 and it occurs on both versions.

Ronald Fenner

unread,
Dec 15, 2024, 11:32:46 AM12/15/24
to v8-dev
SO after a little more digging I dropped an output stmt to print the address, size and access variable being sent for both 12.5.97 and 12.5.96 and there is a difference.
12.5.96 outputs
0x39ec00000000 134217728 0
and a whole bunch of other addresses before it none with 3 all the others are 0,1,2 or 4

12.5.97 outputs
0x39ec00000000 134217728 3 
unlike 12.5.96 it's the only line to be output.

So 12.5.97 is trying to set the memory to ReadWriteExecute where as 12.5.96 it was NoAccess.

It looks like something in my OS doesn't like that access being set for that memory address.

Ronald Fenner

unread,
Dec 25, 2024, 9:06:51 PM12/25/24
to v8-dev
So was finally able to compile v8. I went back to basics on the args and it compiled so i went through. my version of the build args and stripped some of more specific ones out for issues i've had in the past getting it to compile and at least one of them was the result of it.

 One interesting caveat of having v8gen.py generate the args it set my host to x64 to build the target for arm64 which caused a number of failures related to the embedded snapshot it looked like, after correcting the host to arm64 since i'm on an M3 Max chip it compiled.

in particular these had been added for issues related to thin archives being built, an issue with trig functions and turning off the pointer compression shared cage.
    'use_custom_libcxx': 'false',
    'v8_static_library': 'true',
    'v8_enable_pointer_compression_shared_cage ': 'false',
    "v8_use_libm_trig_functions": "false",
    "icu_disable_thin_archive": "true",

I suspect the pointer compression one may be the culprit that caused mksnapshot to crash since it deals with memory.

Hope it helps anyone else in the future.
Reply all
Reply to author
Forward
0 new messages