MacOS x64 build failed while signing with Fatal JavaScript invalid size error with many extraResouces files/folders

[KillerCodeMonkey]

• Electron-Builder Version: 24.13.3

• Node Version: 20.11.1

• Electron Version: 30.0.9 (tried 30.1.0 and latest 31.x version as well)
• Electron Type (current, beta, nightly): stable

• Target: macos x64

Update:

like i stated in my comments below the osx-sign package walks through all the files under "Contents" if you reach a limit of files/size in memory the signing process will die.

In my electron app there is webserver that delivers an angular + ionic app, which is build separately. This folder is put inside the app with "extraResources".

Original

Since some days my builds are failing in github actions, but only for macos when signing.
Without signing it is working. Linux/Win is working as well.

I tried newer electron and node version with the same error.
The strange thing is, that the same build worked with electron 30.1.0 1-2 weeks ago.

Any ideas... i am a little bit glueless.

Thank you

  • electron-builder  version=24.13.3 os=21.6.0
  • artifacts will be published  reason=tag is defined tag=v1.314.1
  • loaded configuration  file=/Users/runner/work/XXX/electron-builder.cjs
  • skipped dependencies rebuild  reason=npmRebuild is set to false
  • packaging       platform=darwin arch=x64 electron=30.0.9 appOutDir=package/mac
  • downloading     url=https://github.com/electron/electron/releases/download/v30.0.9/electron-v30.0.9-darwin-x64.zip size=102 MB parts=8
  • downloaded      url=https://github.com/electron/electron/releases/download/v30.0.9/electron-v30.0.9-darwin-x64.zip duration=4.268s
  • signing         file=package/mac/Standalone.app platform=darwin type=distribution identity=D64A5FA94C0B300606AF05099EDBE99A3AEAE5A1 provisioningProfile=none
#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 188720663 (see crbug.com/1201626)
#
#
#
#FailureMessage Object: 0x7ff7b4cbde60
----- Native stack trace -----
 1: 0x10b394a32 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 2: 0x10c670193 V8_Fatal(char const*, ...) [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 3: 0x10b68c8e6 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray(int, v8::internal::AllocationType) [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 4: 0x10b8716b3 v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 5: 0x10bb096dc v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 6: 0x10bee92b6 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 7: 0x12120c074 
 8: 0x10be5ac9c Builtins_InterpreterEntryTrampoline [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
 9: 0x10be5ac9c Builtins_InterpreterEntryTrampoline [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
10: 0x1211fe638 
11: 0x10be5ac9c Builtins_InterpreterEntryTrampoline [/Users/runner/hostedtoolcache/node/20.11.1/x64/bin/node]
/Users/runner/work/_temp/af2c8ea7-3ff6-40f2-8191-4b7a090bab1a.sh: line 2:  8531 Trace/BPT trap: 5       npx electron-builder --config electron-builder.cjs --mac

[mmaietta]

Any chance you'd be willing to try node 18? I haven't seen this error before tbh and am also not sure why something 1-2 weeks ago would now be throwing errors.

Another guess is that the Github runners for macos-latest were changed to arm64 machines (not sure when GH rolled those out, but I did recently run into CI issues where the macos-latest arch change caused CI tests to start failing for all previous versions of electron-builder, so I needed to make some changes to the CI tests to more get them passing again)

[KillerCodeMonkey]

Thanks for the Response. I noticed that github rolled something out for the runners. Because some older Apps I need to Support used macos-11... and they were hangig to get an available Instance. So there was the fix to build it with macos-12. But for this Problem here. I have no idea. Already switched from macos-latest to 12, 13 and even tried the large versions, because memory is the bottleneck. Using nodejs v18 would force me to downgrade Electron < 30 which is for production purposes not possible. But I can try it tomorrow for a testing round. Am 9. Juli 2024 20:52:18 MESZ schrieb Mike Maietta ***@***.***>:

…

Any chance you'd be willing to try node 18? I haven't seen this error before tbh and am also not sure why something 1-2 weeks ago would now be throwing errors. Another guess is that the Github runners for macos-latest were changed to arm64 machines (not sure when GH rolled those out, but I did recently run into CI issues where the macos-latest arch change caused CI tests to start failing for all previous versions of electron-builder, so I needed to make some changes to the CI tests to more get them passing again) -- Reply to this email directly or view it on GitHub: #8306 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[KillerCodeMonkey]

@mmaietta i tried a self hosted runner (ec2 macos instance) the same error occurs. are there file/content size limits for signing?

my asar has 181mb maybe it hits some memory limit when signing?

Because it is always the same size of 188720663

[KillerCodeMonkey]

i now reduced bundle size so it is 10mb below the last build.. no luck.
Does anyone knows, what the "signing step" does and how such an error can occur?

Some more info: the app uses sharp and better-sqlite3 so we have them in unpack asar option and we are adding 5 additional folders of files to the bundles.

But all is working when not signing...

[mmaietta]

Are you able to create a minimum reproducible repo of this issue that I can investigate locally with? electron-builder uses @electron/osx-sign package under-the-hood, but there are some commands that leverage codesign and keychain-access directly

[KillerCodeMonkey]

i can try, but i think it will be hard to build. That app is quite complex.
But in general what is osx-sign doing with the ".app" archive? because it really errors very fast after the "signing file=package/mac/Standalone.app platform=darwin type=distribution identity=D64A5FA94C0B300606AF05099EDBE99A3AEAE5A1 provisioningProfile=none" logging

[KillerCodeMonkey]

@mmaietta i was not able to reproduce it now. created a new project with electron-vite, added all my dependencies + the native ones. and it builds.

i even tried to add some huge file to the asar so it exceeds my production app.. no luck.

is it possible to activate the debug logs? because i see osx-sign is logging many things on the debug log.
I saw that the sign task is using a walkasync method and runs through all files an folders in the "Content" folder. Maybe something was added there that is causing the error (to deep nested or what ever)...

[KillerCodeMonkey]

it seems really breaking the signing process when there are huge amount of additional files.
Background: we start a webserver inside the electron app, so the user can access a webinterface everywhere in the local network.

This web app (ionic + angular) is bundled separately and just the "www" is put inside the app as "extraResource".

Seems like some files where added there or the build process creates some more files which makes the signing explode.
If i remove that folder form the extraResources the signing process works.

But in general it is not that huge at all. all additional resources are ~65mb and ~2100 files.

So in general it is really easy to break signing with a huge electron app (many files) in general. Strange that nobody else reported it, yet

[KillerCodeMonkey]

I tested it with a new electron-vite (typescript+react) project. just put the build of the angular+ionic app as extra resource and the build fails exact at this signing point with the expected error.

[KillerCodeMonkey]

I worked around the issue for now by reducing the external dependency files added to that angular project.

We are including a specific pdfjs version with all it files. so for now i do not add all the cmaps and only the basic locales (which both is not ideal), but it seems to reduce the files and the size so the signing is back working again..

But we will definitely run in it again.
Since we are using lazy loading routes, each page/route is creating its own chunk file.
So if our app will grow again at some part it will fail again.

[mmaietta]

is it possible to activate the debug logs? because i see osx-sign is logging many things on the debug log.

Yes, you can do so by using env var: DEBUG=electron-osx-sign*
https://github.com/electron/osx-sign?tab=readme-ov-file#debug

Please give it a shot and let me know what logs come back! :)

[KillerCodeMonkey]

@mmaietta there is nothing special in those logs

 • signing         file=dist/mac-arm64/electron-vite-osx-sign.app platform=darwin type=distribution identity=D64A5FA94C0B300606AF05099EDBE99A3AEAE5A1 provisioningProfile=none
2024-07-11T18:12:15.775Z electron-osx-sign electron-osx-sign@1.0.5
2024-07-11T18:12:15.775Z electron-osx-sign `identity` passed in arguments.
2024-07-11T18:12:15.775Z electron-osx-sign Pre-sign operation enabled for provisioning profile: 
 * Disable by setting `pre-embed-provisioning-profile` to `false`.
2024-07-11T18:12:15.775Z electron-osx-sign No `provisioning-profile` passed in arguments, will find in current working directory and in user library...
2024-07-11T18:12:15.776Z electron-osx-sign No provisioning profile found, will not embed profile in app contents.
2024-07-11T18:12:15.776Z electron-osx-sign Signing application... 
 > Application: /Users/runner/work/macos-sign-issue/macos-sign-issue/dist/mac-arm64/electron-vite-osx-sign.app 
 > Platform: darwin 
 > Additional binaries: undefined 
 > Identity: D64A5FA94C0B300606AF05099EDBE99A3AEAE5A1
2024-07-11T18:12:15.776Z electron-osx-sign Walking... /Users/runner/work/macos-sign-issue/macos-sign-issue/dist/mac-arm64/electron-vite-osx-sign.app/Contents


#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 188720663 (see crbug.com/1201626)
#
#
#
#FailureMessage Object: 0x16ced6ed8
----- Native stack trace -----

 1: 0x1030577fc node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 2: 0x104107974 V8_Fatal(char const*, ...) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 3: 0x10331f12c v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 4: 0x1034bad60 v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0>>::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 5: 0x103706640 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 6: 0x103a70c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 7: 0x10926a5b0 
 8: 0x1039e83e4 Builtins_InterpreterEntryTrampoline [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
 9: 0x1039e83e4 Builtins_InterpreterEntryTrampoline [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
10: 0x10925c094 
11: 0x109264edc 
12: 0x1091ef3f8 
13: 0x1039e650c Builtins_JSEntryTrampoline [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
14: 0x1039e61f4 Builtins_JSEntry [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
15: 0x1032be2f0 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
16: 0x1032bd73c v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
17: 0x10319802c v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
18: 0x102f20fa0 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
19: 0x102f37104 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
20: 0x102ffa418 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
21: 0x102ffb120 node::fs::AfterInteger(uv_fs_s*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
22: 0x102feec24 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
23: 0x1039c4228 uv__work_done [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
24: 0x1039c7c78 uv__async_io [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
25: 0x1039d9d50 uv__io_poll [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
26: 0x1039c823c uv_run [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
27: 0x102f216f0 node::SpinEventLoopInternal(node::Environment*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
28: 0x1030348c8 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
29: 0x1030345dc node::NodeMainInstance::Run() [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
30: 0x102fbc7f4 node::Start(int, char**) [/Users/runner/hostedtoolcache/node/20.15.0/arm64/bin/node]
31: 0x1822a20e0 start [/usr/lib/dyld]
/Users/runner/work/_temp/bf0cac92-73f6-4fd4-9c67-1f85b28a5f26.sh: line 2:  2685 Trace/BPT trap: 5       npx electron-builder --config electron-builder.yml --mac

But since i solved it for now by reducing the amount if files i guess that this walkAsync all files in the Contents part is the problem.
I can only imaging that this is the bottleneck

I will try to produce this error without any project depending code and make a public repo.

But i guess if you just add a big amount of files into your extraResources it will fail.

[KillerCodeMonkey]

@mmaietta https://github.com/fdk-app/electron-osx-sign-invalid-size-error i created a repo where the signing fails.

let me know if you have downloaded/forked it. so i would like to remove the public repo again.

Thanks!

[KillerCodeMonkey]

i created an issue at electron/osx-sign#325

I linked this issue and added some more hints, what i think the problem is

Short: all files of "Contents" are processed in parallel (using fs.stat and calling a library to check if it is a binary file). this is calling stat again, reads the first 1000 bytes of each file and uses "Buffer.alloc" for that what will not reuse memory or using the memory pool.

So i guess adding a subjective "big" amount of files to the "Content" folder to sign will easily break the signing process..

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This issue was closed because it has been stalled for 30 days with no activity.