Диагностика

15 отговора 737 прегледа
#1

Диагностика

Колеги, както знаете, добре е като гръмне някъде софтуера да се знае точно къде е гръмнал. В дебъг режим си има callstack, но в клиентската дистрибуцията обикновено липсват всякакви екстри за дебъг.
В предишната фирма хората си бяха направили логинг система, т.е. първия ред на ф-ята ти е LogEvent("влизам в тая ф-я"), а последния, съответно LogEvent("излизам от тая ф-я"). Както можете да се досетите, подобен подход ебава майката на бързодействието и за това се прилагаше само при по-тънките места (по усмотрение на програмиста).
Принципно, идеята е да има callstack, който да се дъмпва при гърмеж. Т.е. вместо LogEvent("влизам в тая ф-я")и LogEvent("излизам от тая ф-я") да има PushPoint("тая ф-я") и PopPoint("тая ф-я").

Понеже ме мързи да го реализирам, пък и боса иска нещо стандартно, ви питам дали има някакви известни подобни callstack системи?

Я вышел им наперерез!
Отговор
в отговор на Resurrector #2

Re: Диагностика

ами за линукс има - нарича се core dump :)
пускаш си го с "ulimit -c unlimited" и като ти гръмне нещо ти прави един core файл, който съдържа паметта на процеса в момента на гърмежа, после това може да го заредиш в дебъгер и да видиш кво е станало

Отговор
в отговор на Resurrector #3

Re: Диагностика

За callstack системи не знам, но в .NET има интересно решение за tracing. Може би ще ти е интересно да хвърлиш едно око на Trace и на другите класове от System.Diagnostics (в случай, че още не си се запознал с тях).

Отговор
в отговор на core #4

Re: Диагностика

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

Я вышел им наперерез!
Отговор
в отговор на ironcode #5

Re: Диагностика

Хм, ние пишем една лека програмка, която се download от нета. ДотНет фреймуорка ни е мнооооого далечен като платформа за разработка. Караме си на старото тъпо МФЦ.

Я вышел им наперерез!
Отговор
в отговор на Resurrector #6

Re: Диагностика

Абе разните джаджи от сорта на BoundChecker не вършат ли работа?

Я вышел им наперерез!
Отговор
в отговор на Resurrector #7

Re: Диагностика

Не, те не са за release код...

Отговор
в отговор на Resurrector #8

Re: Диагностика

V platform SDK -to si ima dbghelp.h bre Mig :) Shto ne go porazgledash.
Mojesh da dympish stekove i t .n

Отговор
в отговор на Resurrector #9

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.

Отговор
в отговор на Resurrector #10

Re: Диагностика

Ние сме направили точно такава система, работи за release версиите, и е малък software, който се download-ва. Ако се интересуваш дай един майл. Не мога да ти дам source по разбираеми причини, но мога да ти дам една две идеи.

Отговор
в отговор на Resurrector #11

Re: Диагностика

това, което съм виждал е серия статии и примерен код от Matt Pietrek. темата беше Structured Exception Handling.

човека даваше пример как да хванеш нехванато изключение, да се поразходиш из информацията и да разбереш в коя функция е възникнало ( последното посредством малко апита и в краен случай с адреса от мап файла )

мисля, че нейде из msdn.microsoft.com още го има

ein heller Schein am Firmament
Отговор
в отговор на ironcode #12

Re: Диагностика

Искаш да кажеш - не са за код без debug info? Въпреки, че предполагаm, че и тогава ще работят - поне що се отнася до невалидни API calls....

Отговор
в отговор на Questor #13

Re: Диагностика

Искам да кажа, че не е хубаво да се използват за production код, защото намаляват производителността драстично. Може да се използват по време на разработката на приложението, но тогава е по-добре да са си в debug build-а. Иначе никой не ти пречи да instrument-ваш production код, но не е добре да се прави така.

Отговор
в отговор на ironcode #14

Re: Диагностика

E pa to izobshto instrumentiran build sha trygne li ako nema instaliran Boundschecker na mashinata :-)

Отговор
в отговор на Questor #15

Re: Диагностика

Май тръгва, но няма кой да го следи

Отговор
в отговор на Resurrector #16

Re: Диагностика

Значи, това за мап файла наистина е хитро и май е почти достатъчно. Единият тесен момент там е, че не се записва версията (само датата), тъй че версията ще трябва да се набива на ръка. Иначе е сигурно, че ще станат бози. Другият е, че все пак, при този подход няма callstack. Т.е. ако, примерно, ф-я в програмата викне някоя ф-я в някой dll с нечитави параметри и длл-ската ф-я, гръмне, ше остана с пръст в уста, щото гърмежа ще е на ебати адреса.

Остава да се направи една малка програмка, която от данните на мап файла и дъмпа на стека да показва коя ф-я е гръмнала и с какви параметри.

Я вышел им наперерез!
Отговор