Mocha: Трассировки стека узлов усечены

Созданный на 19 апр. 2017  ·  3Комментарии  ·  Источник: mochajs/mocha

Я думаю, что это проблема мокко, но трудно сказать, так как мне не с чем сравнивать, хотя это может быть общая экологическая проблема. Мы получаем ошибки из-за нехватки памяти на большом наборе тестов. Я много исследовал это, и кажется, что это может быть одна из нескольких вещей, но на данный момент очень сложно устранить неполадки, потому что я не могу получить полную трассировку стека.

[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

.. и не видел других, которые могли быть связаны. Мысли?

confirmed-bug unconfirmed-bug

Самый полезный комментарий

Продолжение: это не ошибка мокко. Это ошибка 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

Все 3 Комментарий

Продолжение: это не ошибка мокко. Это ошибка 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 и сбой всех сборок, спасибо, что поделились этим

Была ли эта страница полезной?
0 / 5 - 0 рейтинги