Существует ли ограничение на размер стека процесса в Linux

Ответ 1

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

stack size              (kbytes, -s) 8192

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

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

Ответ 2

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

См. man ulimit.

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

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

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

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