Диагностика
15 отговора
737 прегледа
Диагностика
Колеги, както знаете, добре е като гръмне някъде софтуера да се знае точно къде е гръмнал.
В дебъг режим си има callstack, но в клиентската дистрибуцията обикновено липсват всякакви екстри за дебъг.
В предишната фирма хората си бяха направили логинг система, т.е. първия ред на ф-ята ти е LogEvent("влизам в тая ф-я"), а последния, съответно LogEvent("излизам от тая ф-я").
Както можете да се досетите, подобен подход ебава майката на бързодействието и за това се прилагаше само при по-тънките места (по усмотрение на програмиста).
Принципно, идеята е да има callstack, който да се дъмпва при гърмеж. Т.е. вместо LogEvent("влизам в тая ф-я")и LogEvent("излизам от тая ф-я") да има PushPoint("тая ф-я") и PopPoint("тая ф-я").
Понеже ме мързи да го реализирам, пък и боса иска нещо стандартно, ви питам дали има някакви известни подобни callstack системи?
Я вышел им наперерез!
В предишната фирма хората си бяха направили логинг система, т.е. първия ред на ф-ята ти е LogEvent("влизам в тая ф-я"), а последния, съответно LogEvent("излизам от тая ф-я").
Принципно, идеята е да има callstack, който да се дъмпва при гърмеж. Т.е. вместо LogEvent("влизам в тая ф-я")и LogEvent("излизам от тая ф-я") да има PushPoint("тая ф-я") и PopPoint("тая ф-я").
Понеже ме мързи да го реализирам, пък и боса иска нещо стандартно, ви питам дали има някакви известни подобни callstack системи?
Я вышел им наперерез!
Re: Диагностика
ами за линукс има - нарича се core dump :)
пускаш си го с "ulimit -c unlimited" и като ти гръмне нещо ти прави един core файл, който съдържа паметта на процеса в момента на гърмежа, после това може да го заредиш в дебъгер и да видиш кво е станало
пускаш си го с "ulimit -c unlimited" и като ти гръмне нещо ти прави един core файл, който съдържа паметта на процеса в момента на гърмежа, после това може да го заредиш в дебъгер и да видиш кво е станало
Re: Диагностика
За callstack системи не знам, но в .NET има интересно решение за tracing. Може би ще ти е интересно да хвърлиш едно око на Trace и на другите класове от System.Diagnostics (в случай, че още не си се запознал с тях). 
Re: Диагностика
Пиша софт за прозорците, сори.
Пък и тук като ти гръмне имаш пълната информация - адреса на гърмежа, стек, код на грешка и т.н.
Обаче нали се сещаш, че когато в изпълнимия файл няма грам дебъг информация е трудно да определиш кой адрес в коя ф-я се намира (поне за мен).
Я вышел им наперерез!
Пък и тук като ти гръмне имаш пълната информация - адреса на гърмежа, стек, код на грешка и т.н.
Обаче нали се сещаш, че когато в изпълнимия файл няма грам дебъг информация е трудно да определиш кой адрес в коя ф-я се намира (поне за мен).
Я вышел им наперерез!
Re: Диагностика
Хм, ние пишем една лека програмка, която се download от нета. ДотНет фреймуорка ни е мнооооого далечен като платформа за разработка.
Караме си на старото тъпо МФЦ.
Я вышел им наперерез!
Я вышел им наперерез!
Re: Диагностика
Абе разните джаджи от сорта на BoundChecker не вършат ли работа?
Я вышел им наперерез!
Я вышел им наперерез!
Re: Диагностика
V platform SDK -to si ima dbghelp.h bre Mig :) Shto ne go porazgledash.
Mojesh da dympish stekove i t .n
Mojesh da dympish stekove i t .n
Re: Диагностика
linkera pravi map na izpalnimiya file -> taka namirash kade e gramnalo (w koya funkciya) moje da kajesh na kompilatora (predpolagam che towa e C compiler) da
generira listing failowe (naj dobre s mashinen kod, assembler i source lines) i taka mojesh mnogo dobre da se orientirash kakvo e stanalo.
generira listing failowe (naj dobre s mashinen kod, assembler i source lines) i taka mojesh mnogo dobre da se orientirash kakvo e stanalo.
Re: Диагностика
Ние сме направили точно такава система, работи за release версиите, и е малък software, който се download-ва. Ако се интересуваш дай един майл. Не мога да ти дам source по разбираеми причини, но мога да ти дам една две идеи.
Re: Диагностика
това, което съм виждал е серия статии и примерен код от Matt Pietrek. темата беше Structured Exception Handling.
човека даваше пример как да хванеш нехванато изключение, да се поразходиш из информацията и да разбереш в коя функция е възникнало ( последното посредством малко апита и в краен случай с адреса от мап файла )
мисля, че нейде из msdn.microsoft.com още го има
ein heller Schein am Firmament
човека даваше пример как да хванеш нехванато изключение, да се поразходиш из информацията и да разбереш в коя функция е възникнало ( последното посредством малко апита и в краен случай с адреса от мап файла )
мисля, че нейде из msdn.microsoft.com още го има
ein heller Schein am Firmament
Re: Диагностика
Искаш да кажеш - не са за код без debug info? Въпреки, че предполагаm, че и тогава ще работят - поне що се отнася до невалидни API calls....
Re: Диагностика
Искам да кажа, че не е хубаво да се използват за production код, защото намаляват производителността драстично. Може да се използват по време на разработката на приложението, но тогава е по-добре да са си в debug build-а. Иначе никой не ти пречи да instrument-ваш production код, но не е добре да се прави така.
Re: Диагностика
E pa to izobshto instrumentiran build sha trygne li ako nema instaliran Boundschecker na mashinata :-)
Re: Диагностика
Значи, това за мап файла наистина е хитро и май е почти достатъчно.
Единият тесен момент там е, че не се записва версията (само датата), тъй че версията ще трябва да се набива на ръка. Иначе е сигурно, че ще станат бози. Другият е, че все пак, при този подход няма callstack. Т.е. ако, примерно, ф-я в програмата викне някоя ф-я в някой dll с нечитави параметри и длл-ската ф-я, гръмне, ше остана с пръст в уста, щото гърмежа ще е на ебати адреса.
Остава да се направи една малка програмка, която от данните на мап файла и дъмпа на стека да показва коя ф-я е гръмнала и с какви параметри.
Я вышел им наперерез!
Остава да се направи една малка програмка, която от данните на мап файла и дъмпа на стека да показва коя ф-я е гръмнала и с какви параметри.
Я вышел им наперерез!