Наскоро беше внедрен проект в продукционна среда и беше открито, че някои методи изхвърлят аномални съобщения
Въпреки това, се дава само информация за аномални грешки и няма аномален номер на линия, а само че има проблем с преобразуването на модела при определен метод
Но нека ги сравня един по един, твърде е досадно, защо да не запишем грешен номер на линия?
Конфигурацията на log4net log е следната:
Умишлено написах съобщение за изключение в метода Home/Index на местния си компютър, за да видя дали номерът на линията ще бъде записан:
Открих, че файлът за грешки записва номера на линията, което определено не е проблем с конфигурацията на log4net, защото конфигурацията и от двете страни е еднаква
Възможно ли е проблемът да е в режима на компилация???
Моят локален компютър е в debug режим, а DLL-ът, компилиран от официалния сървър, е в режим на release
След това смених локалния проект на release mode и установих, че все още е номер на записна линия.
После, Байду, първото изречение:Трябва да копираш .pdb файла, съответстващ на dll”
Е, това проблем ли е? След това отидох директно в bin-директорията, изтрих .pdb файла, съответстващ на dll-а, и обнових уебсайта, където открих лог с изключения, както следва:
И наистина, необичайният номер на линията не е записан!!!!
Наистина ли е проблем с .pdb!! Трябва да запазите .pdb файла, за да може номерът на линията да бъде записан, ако е ненормален!!
За какво служи PDB файлът?
PDB файлове: Това, което всеки разработчик трябва да знае
Какво е PDB файл?
Повечето разработчици трябва да знаят, че PDB файловете се използват за подпомагане при софтуерно отстраняване на грешки. Но как точно работи, може би не сме запознати. Тази статия описва съхранението и съдържанието на PDB файловете. Той също така описва как дебъгерът намира PDB файла, съответстващ на binay, и как намира изходния кодов файл, съответстващ на binay. Тази статия е за всички Native и Managed разработчици.
Преди да започнем, нека дефинираме два термина: private build, който се използва за означаване на билд, генериран на собствената машина на разработчика; Public Build, което означава билд, генериран на публичен билд машина. частното строителство е сравнително просто, защото PDB и Binay са на едно и също място, а обикновено проблемите са свързани с публичното строителство.
Най-важното, което всички разработчици трябва да знаят, е, че "PDB файловете са също толкова важни, колкото и изходният код", без които дори не можеш да дебъгнеш. За публична конфигурация, сървърът за символи трябва да съхранява всички PDB-та, а когато потребителят докладва грешка, дебъгерът автоматично може да намери съответния PDB файл в binay, а както Visual Studio, така и Windbg знаят как да достъпят сървъра за символи. Преди да съхранявате PDB и binay на сървъра за символи, трябва също да индексирате PDB run, което е да асоциирате PDB и източника.
Следващата част предполага, че Symbol Server и Source Server Indexing вече са настроени. TFS2010 може да се направи толкова просто, колкото индексиране на source и копиране на символен сървър за нова конфигурация.
2. Съдържанието на PDB файла
Официално започвайки съдържанието на PDB, PDB не е публично достъпен файлов формат, но Microsoft предоставя API за получаване на данни от PDB.
Native C++ PDB съдържа следната информация:
* публични, частни и статични адреси на функциите;
* Името и адресът на глобалната променлива;
* Имена и отклонения на параметри и локални променливи в стека;
* типови дефиниции на клас, структура и данни;
* Данни за пропускане на Frame Pointer за преминаване през нативния стек на x86;
* Името и броят на редовете във файла с изходен код;
.NET PDB съдържа само 2 части информация:
* Име на файл с изходен код и брой редове;
* и името на локалната променлива;
* Всички останали данни вече са включени в . NET метаданни;
|
Публикувано в 3.08.2017 г. 14:13:01 ч.
|
|
|
|
