Доброго времени суток всем уважаемым кротам:)
Стал в рабочий проект добавлять вываливание лога в телегу и столкнулся со «stack overflow».
Оно конечно долго зрело и никак не доходило. В процессах сидели как правило небольшие коды для обращения к датчикам или выдаче воздействий. Но пришпиленная либа, производства того, о ком упоминать тут моветон, потребовала большего, чем 4000 бурундуков. Поставил 6000, тестирую.
Но вот вопрос, а как определить сколько именно выделять, как определить разумныы максимум?
Все, что придумывается, это то же самое для 8266 запущенное в рабочем режиме и вывод некоторой статистики по фримему, которую после можно использовать для ESP32 и ртоса, опять же с учетом разных платформ очень условно. Но это же костыли, наверняка есть что то поизящнее? Искал, не нашел, наверно плохо искал. Ведь не методом же научного тыка?
Подскажите плз, кто и как решает этот вопрос 
не знал, что у него есть библиотека, а я использую ту, непростую, проблем пока не было
Увеличенный до 6000 стек пока летит нормально.
Но ведь выделять память «±лапоть» неправильно, и заниматься пристрелкой с долгоиграющими тестами на стабильность тоже бред. Должен же быть какой-то правильный способ?
Через часок поставлю 5000 посмотрю как пойдёт.
Странные вопросы ты задаёшь. Если рботаешь с ардуиной, добился бесперебойной работы и больше не трожь. Ардуине достаточно. А если мозг требует ещё ответов, поищи на форуме костыль в виде макросов по контролю за свободной памятью. Но по хорошему надо бы в нормальной среде отлаживать, где есть профайлеры по отслеживанию параметров работы программы.
если не можешь рассчитать сколько надо памяти, начинай с 1024 и удваивай, пока не станет стабильно работать. У есп32 около 400кБ. НО, если у тебя там течет внутри таски, или ты дошел до 64кБ и все еще не хватает - надо переписывать.
Эх если бы это дело было специфично исключительно для микроконтроллеров.
В этом году как раз на работе было, что утилитка на Free Pascal написанная чтобы парсить кучу текстовых файлов в определенном синтаксисе вдруг начала падать на особо больших наборах данных (порядка нескольких сотен мегабайт).
Оказалось, что это происходило на последней фазе - фазе сортировки результатов парсинга в порядке встречаемости в файлах - вызывался вполне классический TList.CustomSort и ему не хватало 1 Мб дефолтного стека в винде.
Обнаружили это после двух лет использования программы когда в неё просто скормили не 200 Мб данных, а 500.
Поэтому да, вопрос тонкий. Сортировка входит тут очевидно в рекурсию и чёрт его знает какие там алгоритмы, но плохо они справились всего со 100 тысяч строк итоговых после парсинга - я даже не поверил бы что такое может случится. Видимо плохо карта bad case легла когда много значений с одинаковой частотой встречи которая и была критерием сортировки = 1. Но это только предположение.
То есть методом научного тыка
Кстате, 4000 было мало, 5000 хватило, истина посередине.
а запас,если есть память надо выделять, это не тот ресурс, что ты передашь детям и внукам по наследству )))
Стоит, видимо, выделять кратное килобайту значение (1024) - 4096, 5120 и т.д. Или вообще в хексе - 0x1000, 0x1400… Как-то более скрепно получается )))