expo publish 总是以 Javascript 结束 Ubuntu 内存不足
expo publish always ends up in Javascript head out of memory on Ubuntu
我有一台 PC 运行ning Ubuntu 20.04.1 LTS,内存为 16GB。我正在尝试构建 expo react 应用程序的 apk。每当我尝试 运行 expo publish --release-channel channel_name
它总是 运行 内存不足并给我以下堆栈跟踪:
transform[stdout]: ==== JS stack trace =========================================
transform[stdout]:
transform[stdout]: 0: ExitFrame [pc: 0x13cf099]
transform[stdout]: Security context: 0x1ec3465408d1 <JSObject>
transform[stdout]: 1: token(aka token) [0x2ac37c202af1] [0x0acc333004b1 <undefined>:~1916] [pc=0x1ca847032d11](this=0x0acc333004b1 <undefined>,0x158b955c4321 <String[#4]: punc>,0x285cf488fc21 <String[#1]: :>,0x0acc333004b1 <undefined>)
transform[stdout]: 2: next_token [0x2ac37c200119] [0x0acc333004b1 <undefined>:~2287] [pc=0x1ca846a7bc0c](this=0x2ac37c200159 <Object map = 0x1cca2bdcb39>,0x0ac...
transform[stdout]:
transform[stderr]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
transform[stderr]: 1: 0xa093f0 node::Abort() [/usr/bin/node]
transform[stderr]: 2: 0xa097fc node::OnFatalError(char const*, char const*) [/usr/bin/node]
transform[stderr]: 3: 0xb8431e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
transform[stderr]: 4: 0xb84699 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
transform[stderr]: 5: 0xd31055 [/usr/bin/node]
transform[stderr]: 6: 0xd316e6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/bin/node]
transform[stderr]: 7: 0xd3df65 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/bin/node]
transform[stderr]: 8: 0xd3ee15 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
transform[stderr]: 9: 0xd418cc v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
transform[stderr]: 10: 0xd0837b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
transform[stderr]: 11: 0x1049fbe v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
transform[stderr]: 12: 0x13cf099 [/usr/bin/node]
我尝试设置 NODE_OPTIONS=--max_old_space_size=8192,然后在 运行ning v8.getHeapStatistics() 上我看到以下结果:
{
total_heap_size: 5173248,
total_heap_size_executable: 524288,
total_physical_size: 4460520,
total_available_size: 8636951928,
used_heap_size: 3019200,
heap_size_limit: 8640266240,
malloced_memory: 8192,
peak_malloced_memory: 712992,
does_zap_garbage: 0,
number_of_native_contexts: 1,
number_of_detached_contexts: 0
}
即使 max_old_space_size
设置为 8 GB,我仍然得到相同的堆栈跟踪。
为了确保我的节点选项是否正常工作,我将其更改为 NODE_OPTIONS=--max_old_space_size=4096 并获取了它。 v8.getHeapStatistics() 对于 4GB 的结果是:
{
total_heap_size: 5173248,
total_heap_size_executable: 524288,
total_physical_size: 4460744,
total_available_size: 4342034920, <----- this value changed frmo 8GB to 4GB
used_heap_size: 3050272,
heap_size_limit: 4345298944, <----- this value changed frmo 8GB to 4GB
malloced_memory: 8192,
peak_malloced_memory: 712992,
does_zap_garbage: 0,
number_of_native_contexts: 1,
number_of_detached_contexts: 0
}
我有一台类似配置的 MacBook,它在使用 --max_old_space_size=4096 构建 APK 时没有问题。
我尝试将这些值与我的 MacBook 上的值进行比较,它们看起来很相似。我接着运行v8.getHeapSpaceStatistics()
命令。此处的完整输出:https://paste.ubuntu.com/p/5nvdYVmFRf/。此命令的 new_space
部分 space_size
低于我的 MacBook 上的一个:
Ubuntu
{
space_name: 'new_space',
space_size: 1048576,
space_used_size: 298808,
space_available_size: 748648,
physical_space_size: 1014408
},
MacBook
{
space_name: 'new_space',
space_size: 2097152,
space_used_size: 919712,
space_available_size: 127744,
physical_space_size: 2060464
},
我没有任何想法可以尝试,有人可以帮我解决这个问题吗?
节点版本:v12.18.4
Expo cli 版本:3.27.12
Expo SDK 版本:38
它肯定有 Node 或 V8 错误的味道,但目前还没有足够的证据可以确定。获得一个重现案例会很棒,特别是为了找出问题所在并提供足够的细节以便能够修复它:-)
缺少这些,我可以想到一些您可以尝试的事情:
- 尝试使用节点 14。也许它已经被修复了。
- 尝试 运行 带有标记
--nodetect-ineffective-gcs-near-heap-limit
的节点。从查看代码来看,这个标志似乎应该禁用导致抛出 OOM 错误的特定检查。也就是说,如果我们假设某些东西是 broken/buggy 在引擎盖下,那么禁用其中一个症状可能只会导致其他一些症状在接下来的几步中出现...
- 如果您熟悉 C++ 调试,您可以编译 Node 的调试版本,运行 它在 GDB 中,重现崩溃,转到
v8::internal::Heap::RecomputeLimits
框架并四处看看(例如局部变量的值)试图了解情况。
- 带有
--trace-gc
的 运行ning Node 的输出也可能提供一些见解。
我有一台 PC 运行ning Ubuntu 20.04.1 LTS,内存为 16GB。我正在尝试构建 expo react 应用程序的 apk。每当我尝试 运行 expo publish --release-channel channel_name
它总是 运行 内存不足并给我以下堆栈跟踪:
transform[stdout]: ==== JS stack trace =========================================
transform[stdout]:
transform[stdout]: 0: ExitFrame [pc: 0x13cf099]
transform[stdout]: Security context: 0x1ec3465408d1 <JSObject>
transform[stdout]: 1: token(aka token) [0x2ac37c202af1] [0x0acc333004b1 <undefined>:~1916] [pc=0x1ca847032d11](this=0x0acc333004b1 <undefined>,0x158b955c4321 <String[#4]: punc>,0x285cf488fc21 <String[#1]: :>,0x0acc333004b1 <undefined>)
transform[stdout]: 2: next_token [0x2ac37c200119] [0x0acc333004b1 <undefined>:~2287] [pc=0x1ca846a7bc0c](this=0x2ac37c200159 <Object map = 0x1cca2bdcb39>,0x0ac...
transform[stdout]:
transform[stderr]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
transform[stderr]: 1: 0xa093f0 node::Abort() [/usr/bin/node]
transform[stderr]: 2: 0xa097fc node::OnFatalError(char const*, char const*) [/usr/bin/node]
transform[stderr]: 3: 0xb8431e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
transform[stderr]: 4: 0xb84699 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
transform[stderr]: 5: 0xd31055 [/usr/bin/node]
transform[stderr]: 6: 0xd316e6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/usr/bin/node]
transform[stderr]: 7: 0xd3df65 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/bin/node]
transform[stderr]: 8: 0xd3ee15 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
transform[stderr]: 9: 0xd418cc v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
transform[stderr]: 10: 0xd0837b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
transform[stderr]: 11: 0x1049fbe v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
transform[stderr]: 12: 0x13cf099 [/usr/bin/node]
我尝试设置 NODE_OPTIONS=--max_old_space_size=8192,然后在 运行ning v8.getHeapStatistics() 上我看到以下结果:
{
total_heap_size: 5173248,
total_heap_size_executable: 524288,
total_physical_size: 4460520,
total_available_size: 8636951928,
used_heap_size: 3019200,
heap_size_limit: 8640266240,
malloced_memory: 8192,
peak_malloced_memory: 712992,
does_zap_garbage: 0,
number_of_native_contexts: 1,
number_of_detached_contexts: 0
}
即使 max_old_space_size
设置为 8 GB,我仍然得到相同的堆栈跟踪。
为了确保我的节点选项是否正常工作,我将其更改为 NODE_OPTIONS=--max_old_space_size=4096 并获取了它。 v8.getHeapStatistics() 对于 4GB 的结果是:
{
total_heap_size: 5173248,
total_heap_size_executable: 524288,
total_physical_size: 4460744,
total_available_size: 4342034920, <----- this value changed frmo 8GB to 4GB
used_heap_size: 3050272,
heap_size_limit: 4345298944, <----- this value changed frmo 8GB to 4GB
malloced_memory: 8192,
peak_malloced_memory: 712992,
does_zap_garbage: 0,
number_of_native_contexts: 1,
number_of_detached_contexts: 0
}
我有一台类似配置的 MacBook,它在使用 --max_old_space_size=4096 构建 APK 时没有问题。
我尝试将这些值与我的 MacBook 上的值进行比较,它们看起来很相似。我接着运行v8.getHeapSpaceStatistics()
命令。此处的完整输出:https://paste.ubuntu.com/p/5nvdYVmFRf/。此命令的 new_space
部分 space_size
低于我的 MacBook 上的一个:
Ubuntu
{
space_name: 'new_space',
space_size: 1048576,
space_used_size: 298808,
space_available_size: 748648,
physical_space_size: 1014408
},
MacBook
{
space_name: 'new_space',
space_size: 2097152,
space_used_size: 919712,
space_available_size: 127744,
physical_space_size: 2060464
},
我没有任何想法可以尝试,有人可以帮我解决这个问题吗?
节点版本:v12.18.4
Expo cli 版本:3.27.12
Expo SDK 版本:38
它肯定有 Node 或 V8 错误的味道,但目前还没有足够的证据可以确定。获得一个重现案例会很棒,特别是为了找出问题所在并提供足够的细节以便能够修复它:-)
缺少这些,我可以想到一些您可以尝试的事情:
- 尝试使用节点 14。也许它已经被修复了。
- 尝试 运行 带有标记
--nodetect-ineffective-gcs-near-heap-limit
的节点。从查看代码来看,这个标志似乎应该禁用导致抛出 OOM 错误的特定检查。也就是说,如果我们假设某些东西是 broken/buggy 在引擎盖下,那么禁用其中一个症状可能只会导致其他一些症状在接下来的几步中出现... - 如果您熟悉 C++ 调试,您可以编译 Node 的调试版本,运行 它在 GDB 中,重现崩溃,转到
v8::internal::Heap::RecomputeLimits
框架并四处看看(例如局部变量的值)试图了解情况。 - 带有
--trace-gc
的 运行ning Node 的输出也可能提供一些见解。