Есть ли ограничение размера стека процесса в Linux

Question

Есть ли ограничение на stack размер процесса в Linux?Это просто зависит от RAM машины?Я хочу знать это, чтобы ограничить глубину рекурсивных вызовов функции.

Спасибо.

Answer 1

Стек обычно ограничен пределом ресурса. Вы можете увидеть настройки по умолчанию для вашей установки, используя ulimit -a:

stack size              (kbytes, -s) 8192

(это показывает, что у меня 8 МБ, что огромно).

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

Answer 2

Предел может быть установлен администратором.

См. man ulimit .

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

Answer 3

Это в значительной степени зависит от того, какая у вас архитектура (32- или 64-разрядная) и многопоточная или нет.

По умолчанию в однопоточном процессе, то есть в главном потоке, созданном ОС во время exec (), ваш стек обычно будет расти, пока не достигнет чего-то другого в адресном пространстве. Это означает, что на 32-битном компьютере, как правило, можно иметь, скажем, 1G стека.

Однако, это определенно НЕ тот случай в многопоточном 32-битном процессе. В многопоточных процессах стеки совместно используют адресное пространство и, следовательно, должны быть распределены, поэтому они обычно получают небольшой объем адресного пространства (например, 1 МБ), так что можно создавать множество потоков без исчерпания адресного пространства.

Таким образом, в многопоточном процессе он небольшой и конечный, а в однопоточном - в основном до тех пор, пока вы не столкнетесь с чем-то другим в адресном пространстве (что механизм распределения по умолчанию пытается гарантировать, что это не произойдет слишком скоро). 1007 *

В 64-битной машине, конечно, гораздо больше адресного пространства для игры.

В любом случае вы всегда можете исчерпать виртуальную память, в этом случае вы получите SIGBUS или SIGSEGV или что-то еще.

Answer 4

прокомментировал бы принятый ответ, но, видимо, мне нужно больше представителей ....

Истинное переполнение стека может быть незначительным и не всегда вызывать какие-либо сообщения об ошибках или предупреждения. У меня просто была ситуация, когда единственным симптомом было то, что сокет-соединения потерпели неудачу со странными ошибками SSL. Все остальное работало нормально. Потоки могут выполнять malloc (), захватывать блокировки, общаться с БД и т. Д. Но на уровне SSL новые соединения не будут работать.

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

В конце концов обнаружилось, что размер стека был установлен на 8 МБ, и сразу же после его поднятия проблемы исчезли. Снижение стека до 8Mb вернуло проблему (ABA).

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