Error maximum call stack size exceeded npm

I’m opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don’t understand.
• Other (see below for feature requests):

What’s going wrong?

npm install any-module-name-here fails with «Maximum call stack size exceeded».

I’m using npm@5 in various projects already, but it fails to install / update in a project where I have local symlinks in the tree. At least, that is the only difference I can tell so far.

How can the CLI team reproduce the problem?

I can’t share the repo, but I managed to fix the issues with two small hacks:

First npm crashed with «Maximum call stack size exceeded» and this log:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/Cellar/node@6/6.10.2/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'install',
1 verbose cli   '@studio/backend' ]
2 info using npm@5.0.3
3 info using node@v6.10.2
4 verbose npm-session 3581873a35a3b427
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 304 https://registry.npmjs.org/@studio%2fbackend 761ms (from cache)
8 silly pacote range manifest for @studio/backend@^1.6.0 fetched in 783ms
9 verbose stack RangeError: Maximum call stack size exceeded
9 verbose stack     at /usr/local/lib/node_modules/npm/lib/install/node.js:33:42
9 verbose stack     at Array.forEach (native)
9 verbose stack     at exports.create (/usr/local/lib/node_modules/npm/lib/install/node.js:33:25)
9 verbose stack     at /usr/local/lib/node_modules/npm/lib/install/node.js:36:14
9 verbose stack     at Array.forEach (native)
9 verbose stack     at exports.create (/usr/local/lib/node_modules/npm/lib/install/node.js:33:25)
9 verbose stack     at normalizeTree (/usr/local/lib/node_modules/npm/lib/install.js:377:5)
9 verbose stack     at Array.forEach (native)
9 verbose stack     at normalizeTree (/usr/local/lib/node_modules/npm/lib/install.js:379:19)
9 verbose stack     at Array.forEach (native)
9 verbose stack     at normalizeTree (/usr/local/lib/node_modules/npm/lib/install.js:379:19)
9 verbose stack     at Array.forEach (native)
9 verbose stack     at normalizeTree (/usr/local/lib/node_modules/npm/lib/install.js:379:19)
9 verbose stack     at Array.forEach (native)
9 verbose stack     at normalizeTree (/usr/local/lib/node_modules/npm/lib/install.js:379:19)
9 verbose stack     at Array.forEach (native)
10 verbose cwd /Users/max/projects/studio-analyzer
11 verbose Darwin 16.5.0
12 verbose argv "/usr/local/Cellar/node@6/6.10.2/bin/node" "/usr/local/bin/npm" "install" "@studio/backend"
13 verbose node v6.10.2
14 verbose npm  v5.0.3
15 error Maximum call stack size exceeded
16 verbose exit [ 1, true ]

So I went into /usr/local/lib/node_modules/npm/lib/install.js and changed normalizeTree to this:

  function normalizeTree (tree, seen = new Set()) {
    if (seen.has(tree)) {
      return;
    }
    seen.add(tree);
    createNode(tree)
    tree.location = flatNameFromTree(tree)
    tree.children.forEach((child) => normalizeTree(child, seen))
  }

Secondly, npm install that-module failed with «Cannot read property ‘type’ of undefined» and this log:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/Cellar/node@6/6.10.2/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'i',
1 verbose cli   '@studio/backend' ]
2 info using npm@5.0.3
3 info using node@v6.10.2
4 verbose npm-session 9f7ff18ce9a433f1

# heaps of logs with the ideal tree and detail about all my private modules

558 verbose stack TypeError: Cannot read property 'type' of undefined
558 verbose stack     at /usr/local/lib/node_modules/npm/lib/shrinkwrap.js:111:12
558 verbose stack     at Array.forEach (native)
558 verbose stack     at shrinkwrapDeps (/usr/local/lib/node_modules/npm/lib/shrinkwrap.js:103:97)
558 verbose stack     at /usr/local/lib/node_modules/npm/lib/shrinkwrap.js:138:7
558 verbose stack     at Array.forEach (native)
558 verbose stack     at shrinkwrapDeps (/usr/local/lib/node_modules/npm/lib/shrinkwrap.js:103:97)
558 verbose stack     at treeToShrinkwrap (/usr/local/lib/node_modules/npm/lib/shrinkwrap.js:93:5)
558 verbose stack     at /usr/local/lib/node_modules/npm/lib/shrinkwrap.js:76:21
558 verbose stack     at done (/usr/local/lib/node_modules/npm/lib/utils/lifecycle.js:136:5)
558 verbose stack     at LOOP (/usr/local/lib/node_modules/npm/node_modules/slide/lib/chain.js:7:26)
558 verbose stack     at /usr/local/lib/node_modules/npm/node_modules/slide/lib/chain.js:18:7
558 verbose stack     at /usr/local/lib/node_modules/npm/lib/utils/lifecycle.js:333:20
558 verbose stack     at /usr/local/lib/node_modules/npm/node_modules/graceful-fs/polyfills.js:284:29
558 verbose stack     at FSReqWrap.oncomplete (fs.js:123:15)
559 verbose cwd /Users/max/projects/studio-analyzer
560 verbose Darwin 16.5.0
561 verbose argv "/usr/local/Cellar/node@6/6.10.2/bin/node" "/usr/local/bin/npm" "i" "@studio/backend"
562 verbose node v6.10.2
563 verbose npm  v5.0.3
564 error Cannot read property 'type' of undefined
565 verbose exit [ 1, true ]

This was also easy to fix in /usr/local/lib/node_modules/npm/lib/shrinkwrap.js. Basically getRequested(child) may return undefined, so I added this below line 110:

… and 🎉 npm install that-module worked again.

Hope this helps fixing those issue.

supporting information:

• npm -v prints: 5.0.3
• node -v prints: v6.10.2
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: macOS
• Network issues:
  • Geographic location where npm was run:
  • I use a proxy to connect to the npm registry.
  • I use a proxy to connect to the web.
  • I use a proxy when downloading Git repos.
  • I access the npm registry via a VPN
  • I don’t use a proxy, but have limited or unreliable internet access.
• Container:
  • I develop using Vagrant on Windows.
  • I develop using Vagrant on OS X or Linux.
  • I develop / deploy using Docker.
  • I deploy to a PaaS (Triton, Heroku).

Ситуация: заказчик попросил разместить на странице кликабельную картинку, а чтобы на неё обратило внимание больше посетителей, попросил сделать вокруг неё моргающую рамку. Логика моргания в скрипте очень простая:

Код простой, поэтому делаем всё в одном файле:

<!DOCTYPE html>
<html>
<head>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<title>Pulse</title>
	<style type="text/css">
	/*	рамка, которая будет моргать	*/
		.pulse { box-shadow: 0px 0px 4px 4px #AEA79F; }
	</style>
</head>
<body>
	<div id="pulseDiv"> 
    	<a href="#">
      		<div id="advisersDiv">
        		<img src="https://thecode.media/wp-content/uploads/2020/08/photo_2020-08-05-12.04.57.jpeg">
        	</div>
      	</a>
</div>
<!-- подключаем jQuery -->
<script src="https://yastatic.net/jquery/3.3.1/jquery.min.js" type="text/javascript"></script>
<!-- наш скрипт -->
<script type="text/javascript">
	// добавляем рамку
	function fadeIn() {
		// находим нужный элемент и добавляем рамку с задержкой
  	$('#pulseDiv').find('div#advisersDiv').delay(400).addClass("pulse");
  	// затем убираем рамку
  	fadeOut();
	};
	// убираем рамку
	function fadeOut() {
		// находим нужный элемент и убираем рамку с задержкой
   	$('#pulseDiv').find('div#advisersDiv').delay(400).removeClass("pulse");
   	// затем добавляем 
   	fadeIn();
	};
	// запускаем моргание рамки
	fadeIn();
</script>

</body>
</html>

Но при открытии страницы в браузере мы видим, что ничего не моргает, а в консоли появилась ошибка:

❌ Uncaught RangeError: Maximum call stack size exceeded

Что это значит: в браузере произошло переполнение стека вызовов и из-за этого он не может больше выполнять этот скрипт.

Переполнения стека простыми словами означает вот что:

Что делать с ошибкой Uncaught RangeError: Maximum call stack size exceeded

Эта ошибка — классическая ошибка переполнения стека во время выполнения рекурсивных функций.

Рекурсия — это когда мы вызываем функцию внутри самой себя, но чуть с другими параметрами. Когда параметр дойдёт до конечного значения, цепочка разматывается обратно и функция собирает вместе все значения. Это удобно, когда у нас есть чёткий алгоритм подсчёта с понятными правилами вычислений.

В нашем случае рекурсия возникает, когда в конце обеих функций мы вызываем другую: 

То же самое будет, если мы попробуем запустить простую рекурсию слишком много раз:

Как исправить ошибку Uncaught RangeError: Maximum call stack size exceeded

Самый простой способ исправить эту ошибку — контролировать количество рекурсивных вызовов, например проверять это значение на входе. Если это невозможно, то стоит подумать, как можно переделать алгоритм, чтобы обойтись без рекурсии.

В нашем случае проблема возникает из-за того, что мы вызывали вторые функции бесконтрольно, поэтому они множились без ограничений. Решение — ограничить вызов функции одной секундой — так они будут убираться из стека и переполнения не произойдёт:

<script type="text/javascript">
// добавляем рамку
function fadeIn() {
	// находим нужный элемент и добавляем рамку с задержкой
	$('#pulseDiv').find('div#advisersDiv').delay(400).addClass("pulse");
	// через секунду убираем рамку
	setTimeout(fadeOut,1000)
};
// убираем рамку
function fadeOut() {
	// находим нужный элемент и убираем рамку с задержкой
 	$('#pulseDiv').find('div#advisersDiv').delay(400).removeClass("pulse");
 	// через секунду добавляем рамку
	setTimeout(fadeIn,1000)
};
// запускаем моргание рамки
fadeIn();
</script>

Привет, Хабровчане!

Большинство разработчиков, которые использовали рекурсию для решения своих задач, видели такую ошибку:

 RangeError: Maximum call stack size exceeded. 

Но не каждый разработчик задумывался о том, а что означает «размер стэка вызовов» и каков же этот размер? А в чем его измерять?

Думаю, те, кто работают с языками, напрямую работающими с памятью, смогут легко ответить на этот вопрос, а вот типичный фронтэнд разработчик скорее всего задает себе подобные вопросы впервые. Что-ж, попробуем разобраться!

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

О чем ты вообще, автор?

Для статьи важно понимание таких понятий как Execution Stack, Execution Context. Если вы не знаете, что это такое, то советую об этом почитать. На данном ресурсе уже было достаточно хороших статей на эту тему. Пример — https://habr.com/ru/company/ruvds/blog/422089/

Когда возникает эта ошибка?

Разберем на простом примере — функция, которая рекурсивно вызывает сама себя.

const func = () => {
    func();
}

Если попытаться вызвать такую функцию, то мы увидим в консоли/терминале ошибку, о которой я упомянул выше.

А что если подглядеть, сколько же раз выполнилась функция перед тем, как возникла ошибка?

На данном этапе код запускается в Chrome DevTools последней версии на март 2021. Результат будет различаться в разных браузерах. В дальнейшем в статье я упомяну об этом.

Для эксперимента будем использовать вот такой код:

let i = 0;

const func = () => {
  i++;

  func();
};

try {
  func();
} catch (e) {
  // Словили ошибку переполнения стэка и вывели значение счетчика в консоль
  console.log(i);
}

Результатом вывода в консоль стало число в 13914. Делаем вывод, что перед тем, как переполнить стэк, наша функция вызвалась почти 14 тысяч раз.

Магия начинается тогда, когда мы начинаем играться с этим кодом. Допустим, изменим его вот таким образом:

let i = 0;

const func = () => {
  let someVariable = i + 1;
  i++;

  func();
};

try {
  func();
} catch (e) {
  console.log(i);
}

Единственное, что мы добавили, это объявление переменной someVariable в теле функции. Казалось бы, ничего не поменялось, но число стало меньше. На этот раз функция выполнилась 12523 раз. Что более чем на тысячу меньше, чем в прошлом примере. Чтобы убедиться, что это не погрешность, пробуем выполнять такой код несколько раз, но видим одни и те же результаты в консоли.

Почему же так? Что изменилось? Как понять, посмотрев на функцию, сколько раз она может выполниться рекурсивно?!

Магия раскрыта

Отличие второго примера от первого — наличие дополнительной переменной внутри тела функции. На этом все. Соответственно, можно догадаться, именно из-за этого максимальное количество рекурсивных вызовов стало меньше. Что-ж, а что, если у нас будет не одна, а четыре переменных внутри функции? По этой логике, количество рекурсивных вызовов станет еще меньше? Проверим: 

let i = 0;

const func = () => {
  let a = i + 1;
  let b = a + 1;
  let c = b + 1;
  let d = c + 1;
  let e = d + 1;
  i++;

  func();
};

try {
  func();
} catch (e) {
  console.log(i);
}

По этой логике, значение счетчика должно стать еще меньше. Выдыхая, видим вывод — 8945. Ага, оно стало еще меньше. Значит, мы на правильном пути. Хочу привести небольшую аналогию, чтобы даже самым маленьким стало понятно.

Execution Stack (Call Stack) — это емкость с водой. Изначально она пустая. Так получилось, что эта емкость с водой стоит прямо на электрической проводке. Как только емкость переполнится, вода проливается на провода, и мы видим ошибку в консоли. При каждом новом рекурсивном вызове функции в стэк падает капелька воды. Само собой, чем капелька воды крупнее, тем быстрее наполнится стэк.

Емкости бывают разные по размеру. И размер емкости в данном примере — это размер коллстэка. А точнее — количество байт, которое он максимально может в себе удержать. Как гласит статья про Call Stack (Execution Stack), которую я приложил в начале, на каждый вызов функции создается Execution Context — контекст вызова функции (не путать с this). И упрощая, в нем, помимо разных «подкапотных» штук, содержатся все переменные, которые мы объявили внутри функции. Как Execution Context, так и каждая переменная внутри него имеют определенный размер, который они занимают в памяти. Сложив эти два размера мы и получим «размер» капли, которая капает в кувшин при каждом рекурсивном вызове функции.

У нас уже достаточно много данных. Может быть, поэкспериментируем еще? А давайте попробуем вычислить, какой размер коллстэка в движке, который использует Chrome?

Математика все-таки пригодилась

Как мы выяснили, у нас есть две неизвестные, которые составляют размер функции (капельки, которая падает в емкость). Это размер самого Execution Stack, а так же сумма размеров всех переменных внутри функции. Назовем первую N, а вторую K. Сам же неизвестный размер коллстэка обозначим как X.

В итоге — количество байт, которое занимает функция (в упрощенном виде) будет:

SizeOfVar в данном случае — количество байт, которые занимает переменная в памяти.

Учитывая, что мы знаем количество вызовов первой функции, в теле которой не объявляются переменные, размер коллстэка можно выразить как:

И, для второго случая, возьмем функцию, внутри которой было объявлено пять переменных.

Иксы в обоих случаях обозначают одно и то же число — размер коллстэка. Как учили в школе, можем приравнять правые части уравнений.

Выглядит неплохо. У нас тут две неизвестные переменные — N и SizeOfVar. Если N мы не можем откуда-то узнать, то что насчет SizeOfVar? Заметим, что во всех функциях, которые фигурировали выше, переменные хранили значение с типом «number», а значит, нужно просто узнать, сколько же байт в памяти занимает одна такая переменная.

С помощью великого гугла получаем ответ — «Числа в JavaScript представлены 64-битными значениями с плавающей запятой. В байте 8 бит, в результате каждое число занимает 64/8 = 8 байт.» Вот она — последняя неизвестная. 8 байт. Подставляем ее в наше уравнение и считаем, чем равно N.

Упрощаем:

Если выразить отсюда N, то получим ответ: N равно приблизительно 72. В данном случае 72 байтам.

Теперь, подставив N = 72 в самое первое уравнение, получим, что размер коллстэка в Chrome равен… 1002128 байтов. Это почти один мегабайт. Не так уж и много, согласитесь.

Мы получили какое-то число, но как убедиться, что наши расчеты верны и число правильное? А давайте попробуем с помощью этого числа спрогнозировать, сколько раз сможет выполниться функция, внутри которой будет объявлено 7 переменных типа ‘number’. 

Считаем: Ага, каждая функция будет занимать (72 + 7 * байт, это 128. Разделим 1002128 на 128 и получим число… 7829! Согласно нашим расчетам, такая функция сможет рекурсивно вызваться именно 7829 раз! Идем проверять это в реальном бою…

Важное примечание

Размер стэка разнится от браузера к браузеру. Возьмем простейшую функцию из начала статьи. Выполнив ее в Сафари получим совершенно другую цифру. Целых 45606 вызовов. Функция с пятью переменными внутри выполнилась бы 39905 раз. В NodeJS числа очень близки к Chrome по понятным причинам. Любопытный читатель может проверить это самостоятельно на своем любимом движке JavaScript. 

А что с непримитивами?

Если с числами все вроде бы понятно, то что насчет типа данных Object? 

let i = 0;

const func = () => {
  const a = {
    key: i + 1,
  };
  i++;

  func();
};

try {
  func();
} catch (e) {
  console.log(i);
}

Простейший пример на ваших глазах. Такая функция сможет рекурсивно вызваться 12516. Это практически столько же, сколько и функция с одной переменной внутри. Тут в дело вступает механизм хранения и передачи объектов в JS’е — по ссылке. Думаю, большинство уже знают об этом.

А что с этим? А как поведет себя вот это? А что с *?

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

Итоги:

• Количество рекурсивных вызовов функции до переполнения стэка зависит от самих функций.

• Размер стэка измеряется в байтах.

• Чем «тяжелее» функция, тем меньше раз она может быть вызвана рекурсивно.

• Размер стэка в разных движках различается.

Вопрос особо любознательным: А сколько переменных типа «number» должно быть объявлено в функции, чтобы она могла выполниться рекурсивно всего два раза, после чего стэк переполнится?