-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacOS x64 build failed while signing with Fatal JavaScript invalid size error with many extraResouces files/folders #8306
Comments
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) |
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: ***@***.***>
|
@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 |
i now reduced bundle size so it is 10mb below the last build.. no luck. 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... |
Are you able to create a minimum reproducible repo of this issue that I can investigate locally with? electron-builder uses |
i can try, but i think it will be hard to build. That app is quite complex. |
@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. |
it seems really breaking the signing process when there are huge amount of additional files. 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. 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 |
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. |
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. |
Yes, you can do so by using env var: Please give it a shot and let me know what logs come back! :) |
@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 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. |
@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! |
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.. |
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
The text was updated successfully, but these errors were encountered: