Я думаю, что это проблема мокко, но трудно сказать, так как мне не с чем сравнивать, хотя это может быть общая экологическая проблема. Мы получаем ошибки из-за нехватки памяти на большом наборе тестов. Я много исследовал это, и кажется, что это может быть одна из нескольких вещей, но на данный момент очень сложно устранить неполадки, потому что я не могу получить полную трассировку стека.
[email protected] , [email protected]
<--- Last few GCs --->
82518 ms: Mark-sweep 807.1 (1039.7) -> 802.3 (1038.7) MB, 149.2 / 0.0 ms [allocation failure] [GC in old space requested].
82668 ms: Mark-sweep 802.3 (1038.7) -> 802.3 (1036.7) MB, 150.6 / 0.0 ms [allocation failure] [GC in old space requested].
82838 ms: Mark-sweep 802.3 (1036.7) -> 802.2 (993.7) MB, 169.7 / 0.0 ms [last resort gc].
82989 ms: Mark-sweep 802.2 (993.7) -> 802.2 (982.7) MB, 150.6 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0000024EE58CFB61 <JS Object>
1: SparseJoinWithSeparatorJS(aka SparseJoinWithSeparatorJS) [native array.js:~75] [pc=000002B8298FC057] (this=0000024EE5804381 <undefined>,w=0000011715C4D061 <JS Array[7440]>,F=000003681BBC8B19 <JS Array[7440]>,x=7440,I=0000024EE58B46F1 <JS Function ConvertToString (SharedFunctionInfo 0000024EE5852DC9)>,J=000003681BBC8AD9 <String[4]\: ,\n >)
2: DoJoin(aka DoJoin) [native array.js:137...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Как видите, он его урезает. Я пробовал все, что мог придумать, но ни один из параметров командной строки node
имеет никакого эффекта, например
node --stack_trace_limit=1000 --max_stack_trace_source_length=1000 ./node_modules/mocha/bin/_mocha ./test --full-trace
Я просмотрел все варианты v8 с stack
здесь:
node --v8-options | grep -B0 -A1 stack
.. и не видел других, которые могли быть связаны. Мысли?
Продолжение: это не ошибка мокко. Это ошибка Babel - или, как минимум, область, в которой действительно можно было бы улучшить Babel.
Одна вещь, о которой я здесь не упомянул, - это мой mocha.opts
который включает следующее: --compilers js:babel-core/register
- который является источником проблемы.
После некоторой болезненной отладки я обнаружил, что точка входа в сбой v8 в babel-register/lib/cache.js
... v8 взрывается при попытке сериализовать 200-мегабайтный объект JSON в методе save()
. Почему у меня есть объект JSON размером 200 мегабайт? Хорошо...
«babel-register» очевидно кэширует данные о файлах, которые он компилирует по умолчанию, и сохраняет их в файл. Глядя на cache.js
, кажется, что он никогда не беспокоится о том, насколько велик становится кеш, и никогда не истекает срок его действия. По сути, он просто читает JSO из файла при запуске, добавляет в него данные и записывает его после завершения.
Мои .babel.json
были почти 200 мегабайт. Я сдул его, и все снова заработало. Вы можете полностью отключить кеш, см. Документ babel-register , хотя время от времени его протирание кажется лучшим для производительности. Я ни разу не прикасался к этому за два года, так что полагаю, это было полно всякой чепухи. Мои тесты выполнялись примерно в 10 раз быстрее после того, как я уничтожил кеш (во всяком случае, на втором прогоне, после того, как кеш был восстановлен с моим текущим состоянием).
Я до сих пор не знаю, почему трассировки стека обрезаются.
Отчет об ошибке: https://github.com/babel/babel/issues/5667
Спасибо, что поделились своими выводами! :)
Происходило на нашем сервере CI и сбой всех сборок, спасибо, что поделились этим
Самый полезный комментарий
Продолжение: это не ошибка мокко. Это ошибка Babel - или, как минимум, область, в которой действительно можно было бы улучшить Babel.
Одна вещь, о которой я здесь не упомянул, - это мой
mocha.opts
который включает следующее:--compilers js:babel-core/register
- который является источником проблемы.После некоторой болезненной отладки я обнаружил, что точка входа в сбой v8 в
babel-register/lib/cache.js
... v8 взрывается при попытке сериализовать 200-мегабайтный объект JSON в методеsave()
. Почему у меня есть объект JSON размером 200 мегабайт? Хорошо...«babel-register» очевидно кэширует данные о файлах, которые он компилирует по умолчанию, и сохраняет их в файл. Глядя на
cache.js
, кажется, что он никогда не беспокоится о том, насколько велик становится кеш, и никогда не истекает срок его действия. По сути, он просто читает JSO из файла при запуске, добавляет в него данные и записывает его после завершения.Мои
.babel.json
были почти 200 мегабайт. Я сдул его, и все снова заработало. Вы можете полностью отключить кеш, см. Документ babel-register , хотя время от времени его протирание кажется лучшим для производительности. Я ни разу не прикасался к этому за два года, так что полагаю, это было полно всякой чепухи. Мои тесты выполнялись примерно в 10 раз быстрее после того, как я уничтожил кеш (во всяком случае, на втором прогоне, после того, как кеш был восстановлен с моим текущим состоянием).Я до сих пор не знаю, почему трассировки стека обрезаются.
Отчет об ошибке: https://github.com/babel/babel/issues/5667