Някой срещал ли е нещо ново по темата?

Не виждам нищо ново откакто се появи -fstack-usage и едно Perl скриптче

Евентуално разните static code анализатори, или по-динамични - не помня Klockwork дали го имаше, или PRQA? Ако е за опън сорс доста от тях има безплатни опции.
Тук има въпрос
https://stackoverflow.com/questions/6387614/how-to-determine-maximum-stack-usage-in-embedded-system-with-gcc
и отговора води до тук:
https://github.com/PeterMcKinnis/WorstCaseStack
Имам спомен че някой от инструментите, които са налични като екстри в github го прави това (можеш да активираш различни допълнения към проекта си). Но гледам сега че ги спират и не намирам подходящите.
Но тук има добра колекция от инструменти - може някой от тях да ти свърши работа:
https://github.com/mre/awesome-static-analysis

Тези уж точно това хващат - имат free trial:
https://www.absint.com/stackanalyzer/index.htm

Или просто при буут запълваш стека с патърн, пускаш да работи известно време, спираш и гледаш

Голям шанс има да видиш ... нищо, а после "шанс 1:1000000, а при клиент се чупи 8 от 10 пъти..."

Последния път бях объркал поинтер на един тъп цикъл, ама пусто броеше до доста... стека на 4 таска на кокал, с все сервизната зона на шедълера.... класика в жанра, баси ексепшъна, 2 дена заминаха... Сам си го сътворих, сам си го ядох...

Тези са едните, но за триала ти правят индивидуален лиценз и искат сериозен контакт, демек няма да стане всеки месец да си прося нов лиценз... Все пак може и да ги пробвам поне веднъж

Друг вариант уж са бившите Atolic (сега ST ги купиха), та тяхното TrueStudio май има такава екстра. Някой ако го има инсталирано да каже?

Вариантите със скрипт на базата на -fstack-usage не ми вършат работа, понеже GCC дъмпва функциите с техните декларации в *.su файловете, докато в листингите Ц++ функциите са с декорираните си имена. Така всички тулчета и скриптчета дето разгледах увисват. Един пич е направил патч за gcc... ама да патчвам GCC-то нещо не ме кефи. Освен това за асемблерски функции няма решение. С две думи тоя сорт решения са само за чисто Ц, а аз такова почти нямам..

Варианта с гледане е ясен... но неприложим, понеже проблемите се случват на полето и до нас достигат само слухове. Много трудно е да се хване точната ситуация, за да се повтори. За съжаление се опасявам, че слуховете са верни, понеже последната 1-2 години правихме доста революции на тема общия код да се изнася в библиотеки. Така даден библиотечен код се ползва от десетки проекти, компилира се с различни опции, викат се различни функции... Та с две думи склонен съм да вярвам, че има проблемни ситуации. С тестване и гледане няма да стане, твърде много код в много вариации, все едно да търсиш игла в купа сено. Надеждата ми е да намеря статичен анализатор и да го пусна за всяка една комбинация...

Между другото това беше повод да си ъпдейтна cppcheck-а. Спокойно мога да го похваля... и преди откриваше буболечки, но последната версия доста добре се справя. Ех, като го пуснеш с всички опции дава и доста фалшиви забележки... т.е. отваря много работа за разглеждане. Но си струва, тук няколко дена само това правя. Жалко само че не хваща препълване на стека

Последното което ме впечатли на тази тема е PVS Studio - силно го препоръчвам. Има възможност да работи безплатно ако се добави коментар във файловете , но се намира и пиратски лиценз ...
Впечатляващото е как се закача към кода: пускаш му мониторен процес (с администраторски права първия път) и той следи дали отнякъде не се е пръкнал нов процес с име отговарящо на gcc или майкрософските компилатори - ако ги хване такива им обръща хастара - прихваща целия вход към gcc процеса и изход, и оттам вижда всички опции от командния ред барабар с имена на файлове и т.н., хваща и отворени файлове от гцц-то слец като е пуснато и т.н.
Якото в тоя подход е че не ти трябва никаква интеграция в среда или настройки на билд процеса ти - мейк, еклипс, .... А иначе хваща много проблеми.
Другото интересно е че подхода им какви проблеми да ловят е силно практичен - да правят проверки за често срещани и трудни за хващане неща. Като пример много яко се обажда с подсещане че два сегмента код изглеждат странно еднакво и пита да не е копи-пейст грешка...

аз до колкото разбрах Миро иска динамично на желязото да логва и анализира стека и проблемите
освен с яко реализиран syslog, нема как да стане, а там пак ще позваш патерни и ватер-маркове...

Не, иска гцц да му рапортува при билд колко е worst case използването на стека - поне аз така го разбрах.

Да, питането ми е за статичен анализ. За предпочитане с възможност за настройки, така че да мога аз да му кажа кои са ми сорсовете, кои са ми нишките и т.н. Това с подслушването не ми звучи особено удачно, но ако нямам избор...

За динамичния анализ имаме няколко капанчета и те щракват със сигурност. Верно има някакъв шанс да щракат поради мазане по паметта, а не от препълване на стека. Може да се помисли и над темата за по-качествени капани. Но доколкото си познавам кода мисля, че гърмежите идват от стековете и ако намеря читав анализатор проблемите ще се решат. Докато с подобрение на капаните първо отнема време докато ги заложа, докато почнат да гърмят и докато ми върнат отзиви... ще минат месеци. И второ с капан само ще докажа евентуално причината за някои проблеми. Примерно ще видя че еди коя си нишка си препълва стека и ще го вдигна, но без статичния анализ увеличението може и да не е достатъчно, т.е. пак още няколко месеца...

върти ми се една еретична идея в главата...

Значи ако се парсне листинга може да се извадят всички функции, коя функция колко стек яде, какви други функции вика. Изобщо цялата информация я има в листинга и подлежи на парсване. При това не зависи дали функциите са писани на асемблер, чисто Ц или Ц++.
Като гледам самото парсване, т.е. извличането на базовата информация няма да е чак толкова сложно. Еднозначно се разпознават и функции и всичко. Но обемът на данните е голям и обработките ще са доста. На един пас не мисля че може да стане. Може би в първия пас трябва да смели текстовия файл до нещо по-удобно за търсене и обхождане. Не знам какво да е това. База данни би свършила работа, но искам да стане просто тулче за което да няма нужда от други инсталации. Така че някакви файлове с някакво кеширане... не знам.
Идеята на първи пас да се изкара списък на всички функции, като за всяка функция се сметне колко стек яде, както и какви други функции вика. След това на всеки следващ пас да се търси функция, която не вика други, т.е. нейния стек е ясен. Като се намери такава функция се маха от базата, както и навсякъде където се вика. Естествено преди да се махне от списъка на викащата функция се ъпдейтва стека на викащата.
С две думи както се кастри дърво... махат се листата, докато може нещо да се махне. В идеалния случай всичко ще се махне. В лошия ще останат рекурсиите и взаимно викащи се функции... Аз такива ситуации почти нямам, но за всеки случаи трябва да се направи както правят всички анализатори - предупреждават че има рекурсии и смятат стековете само при 1 ниво на вложеност.

Ето пример как изглежа листинга:

Всяка функция започва с адрес, декларация и накрая ":". Тялото винаги е навътре с няколко интервала и накрая винаги завършва с празен ред. По средата никога няма празен ред.
За стека има няколко инструкции, едната очевидно е "push" и е по 4 байта по броя на регистрите. Другата е sub. В тоя пример размера на стека е 16 байта + колкото използва <CSTRING::assign(char const*)>...

Ех мога да дам и по-засукан пример... тук между другото компилаторът си е оставил ръцете, но това е друга бира. Мисълта ми е, че не е rocket science... малко повече текстообработка и мисля че може да се направи??

Опитваш се да преоткриваш на Keil компилатора за 8051.
И това умира при викане на функции през указател.

Aбе аз функции почти не викам през указател, но за сметка на това имам доста виртуални методи

Чат-пат ц++ компилатора може и да познае кой точно виртуален метод викаш и да го извика директно без да минава през указател - ама толкова рядко, че не си струва да разчиташ на това т.е. и сам знаеш, че няма как да се сметне прецизно дълбочина на стека и от там идва и логичния въпрос за чий въобще ти е да тръгваш в тази посока вместо да си направиш една свястна рънтайм система за мониторинг на блокирани нишки и препълнени стекове и здраво тестване след това преди релийз.

Статичният анализ би било най-чистото решение. С тестване какво да ти кажа, имаме тестери на пълно работно време, откриват някои неща, но няма как да се открие всичко. И системи имаме и точно щото хващат проблеми и ги показват клиентите се шашкат и реват.
То всъщност ако не намеря анализатор явно проблемите ще се търсят по трудния начин, т.е. в посоките които казваш....