Размер стека процесса, можно ли увеличить?

https://stackoverflow.com/questions/2279052/increase-stack-size-in-linux-with...

код не мой

Тогда нет.

LD_FLAGS=-Wl,--stack,100500

Не работает такое на Linux. Как я понял, этот ключ работает на Windows.

Я проверил.

g++-7 1.cpp -Wl,--stack,100500
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: unrecognized option '--stack'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status

Но зато перечитал ключи для gcc и нашел -fsplit-stack

С ним стек стал больше. 1 гигабайт по крайней мере работает. Только для linux.

ulimit -s unlimited

На openvz каком-нить ругнется - мол, хер вам, жрите 8 Мбайт.

Просто интересно - это кто-то пишет ПО, которое на размер стэка завязано используя какие-то особые техники оптимизации и построения архитектуры ПО?

Видимо, всякие go поделия легко могут на такое дело ругаться.

Видал я, как тип в процессинге транзакций финансовых, свои потоки со скуки запилил. Я думал, вдруг это какой то полезный тренд?

Да и в go наверное всё же как во всяких доморощенных корутинах, весь стек на куче, со своим планировщиком в юзерспейсе не?

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

И вот в этом коде за раз (в конструкторе объекта) выделяется на стеке три массива длинной в WCHAR_MAX (WCHAR_MAX == 2147483647). При этом два из массивов состоят из элементов длинной 4 байта, а один - состоит из элементов, где каждый имеет размер в 16 байт.

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

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

ulimit -s unlimited

В итоге я просто от фонаря поделил WCHAR_MAX на 8 и этого уже хватило и для того что бы не падало и для работы алгоритма на тестовом множестве данных.

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

не, это классика, си++.

Причем перенеся в кучу в линуксе всеравно на таких объёмных массивах крошится в сегфолт.

Даже интересно стало, с каким стектрейсом.

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

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

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

О, ну это чудеса анализа, давайте поправим магические числа, авось заработает. Заработало? Вроде заработало, надо порадовать клиента, а завтра пусть Петя с этим делом сношается :)

В карму веришь?

пасяб, пригодится. Правда не в этой задачи, там уж слишком большой объем памяти требуется :)

пасяб :)

не верю, но верю с совесть :)

Но на стектрейс посмотрю, действительно интересно.

выделяется на стеке три массива длинной в WCHAR_MAX

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

Всё гораздо прощё.

Вот такой код

#include <cstdint>
#include <iostream>
int main()
{
        std::cout << WCHAR_MAX << std::endl;
}

выведет на Linux:

./a.out
2147483647

./a.exe
65535

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