node.js - expo publish 总是以 Ubuntu 上的 Javascript head out of memory 结束

Question

我有一台运行 Ubuntu 20.04.1 LTS 和 16GB RAM 的 PC。我正在尝试构建一个 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 然后在运行 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 选项是否正常工作，我将其更改为 NODE_OPTIONS=--max_old_space_size=4096 并获取它。 4GB 的 v8.getHeapStatistics() 的结果是:

{
  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 上低于 1:

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
  },

我没有任何想法可以尝试，有人可以帮我解决这个问题吗？
Node 版本:v12.18.4
Expo cli版本:3.27.12
世博sdk版本:38

Answer 1

它肯定有 Node 或 V8 错误的味道，但到目前为止还没有足够的证据可以确定。获得一个复制案例会很棒，尤其是为了找出问题所在，有足够的细节来修复它:-)
缺乏这一点，我可以想到一些你可以尝试的事情:

尝试使用 Node 14。也许它已经修复了。

尝试运行带有 --nodetect-ineffective-gcs-near-heap-limit 标志的 Node .从代码来看，这个标志似乎应该禁用导致 OOM 错误被抛出的特定检查。也就是说，如果我们假设某些东西在引擎盖下坏了/有问题，那么禁用其中一个症状可能只会导致其他一些症状在接下来的几步中出现......

如果您对 C++ 调试感到满意，您可以编译 Node 的 Debug 版本，在 GDB 中运行它，重现崩溃，转到 v8::internal::Heap::RecomputeLimits框架并环顾四周(例如局部变量的值)以尝试了解情况。

使用 --trace-gc 运行 Node 的输出也可能提供一些见解。