Я делал таким образом (в Release-режиме):
1. Компилю ядро, запускаю. 2. В студии выбираю Debug -> Attach to process -> mangosd.exe (в названиях мог ошибиться, т.к. студии под рукой нет). 3. Потом в нужных местах расставляю точки остановки и нажимаю F10 для дальнейшего перехода по строкам. Данный способ посоветовала Laise, за что ей большое спасибо, т.к. сам не знал.:) Правда, с СД2 такой номер не прокатывает, отладку так и не получилось запустить. |
если в опция линкера не стоит "Generate debug info", то ничего дебажится не будет
проверьте в СД2 в свойствах проекта Configuration properties - Linker - Debugging - Generate debug info если стоит No, то отладка при помощи VS будет невозможна |
Ну, во-первых, надо собирать все проекты в debug mode(в том числе и СД2).
Вот вкратце : 1. Приаттачить студию для отладки можно к любому процессу, если открыт нужный проект, потому что отладка скриптов требует открытый СД2 проект например, а отладка авторизации на сервере потребует аттач к realmd.exe, а не к mangos.exe Так же отладка одного потока останавливает все, т.е вы ткнули бряк на каст спелла - прок, и вы не сможете отследить какие-то другие приходящие клиентские ответы, время как бы "замораживается". См. ниже фильтр потоков 2. Breakpoints - просто ставится напротив нужной строчки по щелчку мыши Настройки бряков : Location - можно задать местоположение брекпойнта через имя файла и номер строки Condition - выполнение брекпойнта не просто по активации, а можно задать какое-то условие, два свойства, логическое - и проверить на true(Is true) или например изменение значения переменной(Has changed) Hit Count - количество "проков" брекпойнта(или прокать всегда(break always)), например вам нужно прокнуть его всего два раза, место такое, ну например мув пакет, что приходит при любом движении мыши, очень неудобно когда куча проков и не знаешь какой когда и где произошел, а с этой опцией все гуд. По умолчанию 0 - срабатывает бесконечное число раз. Filter - фильтр процессов и потоков, например вам нужна активация от конкретного потока(их почти всегда несколько) или процесса, соотв. фильтр по имени или номеру When Hit - когда бряк прокнулся, что-то сделать - например напечтать сообщение, исполнить макрос(подробнее ниже) или просто продолжить выполнение функции/процедуры/метода - как бы пропустив брекпойнт(не останавливая процесс/приложение) http://habrahabr.ru/blogs/net/102178/ - еще более подробно) 3. Трассировка Так всеми вами любимый F10 - Step Over(Шаг с обходом) - делает трассировку основного кода в стеке, проходя(пропуская) другие функции, используется когда нужно быстро пробежатся по коду, просмотреть пару переменных и получить конечный результат Step Into(Шаг с заходом) - трассировка с заходом в каждую встреченную функцию и переход трассировки на код этой функции. Я почти всегда пользуюсь этим видом, а не "F10" Step Out(Шаг с выходом) - банальный выход из функции, где прокнул бряк, естественно с нужным возвратом результатов выполнения и т.д 4. Окна Autos - текущие состояния переменных(массивов, контейнеров и т.д) - в текущий момент(т.е грубо говоря, на желтой полоске) Locals - локальные переменные внутри функции, где в данный момент происходит трассировка Call Stack - стек вызовов, вся цепочка - приводящая к проку брекпойнта, обычно начинается от ворлдовского таймера(потока) и заканчивается нашей функцией, можно проследить вызовы, просто щелкая по нужным функциям Breakpoints - окно брекпойнтов Command Window - командная строка, здесь неактуально Immediate Window - отладочное окно, можно высчитывать результат функций, которые возвращают какое-то значение, ну например CalculateDamage, записав в таком виде Код:
?CalculateDamage(параметры) Output - окно вывода, например информации о компиляции и т.д, думаю все понятно, можно перенаправлять на это окно выводы с функций, но здесб не буду рассказывать, это не столь необходимо, когда есть breakpoint hit и отладочное окно Watch 1...4 - окно просмотра значений переменной/массива, правой кнопкой мыши на переменную/массив и Add Watch. Для чего надо - например вам нужно отследить изменение переменной/массива в процессе трассировки функции, добавляется ватч - и просто трассируете и смотрите в это окошко - не надо каждый раз искать в коде эту переменную/массив и наводить указатель мыши для получения значения, а так же можно прям в этом окошке редактировать значения. Quick Watch - тут же показывает вам результат/значение мгновенно. Threads, Processses, Modules : Окно потоков(как я уже говорил, в момент прока бряка могут выполнятся еще потоки - например пришел от клиента пакет иди запрос к БД) Окно загруженных библиотек(модулей) - (dll и информация о них, например адрес в памяти отлаживаемого процесса)(первый модуль - само приложение, адрес обычно стандартный для PE Windows - 0x00400000) Окно отлаживаемых процесссов(да, их может быть несколько) Memory 1...4 - снимок памяти данного участка в hex-виде, можно указать конкретный адрес Disassembly - показывает все в ассемблерном коде Ну вот и все, да, просмотреть вручную какие-то значения или данные можно, просто наведя мышку на нужный участок(переменная и т.д) при остановке и срабатывании бряка Вот чем я обычно пользуюсь. Кому надо подробнее - гуглите) |
Почему надо собирать ядро именно в debug-режиме, ведь отладка также работает и в release?
|
Цитата:
|
И трассировка работает, и все вышеперечисленные свойства? Насколько я знаю, сборка дебаг содержит отладочную информацию, которая как раз и позволяет вычислять заничения переменных, отслеживать вызовы функций и т.д. Да и в IDA код проще смотрится) Если б близы собирали в дебаге....)) :D
|
Если отключить всю оптимизацию (иначе отладчик VS будет глючить) и включить генерацию отладочной информации, то вполне можно и в релизе отлаживать. Но смысл?
|
Отладку всегда делаю в релизе, глюков не наблюдал.:)
|
Вложений: 5
<reseved>
|
Цитата:
http://img411.imageshack.us/img411/5412/gggoo.png |
Отличный мануал, всем спасибо.
Топикстартеру: 6)Не Забываем положить в папку bin\Win32_Debug\ Достаточно положить один конфиг, рилмд рапускать из рабочей папки сервера, а путь до ДБЦ и карт прописать в конфиге ;) |
Путь к картам и дбц понятно,а вот насчет запуска реалмд ,наверно и так можно?
Примечание: Возможно можно еще и так - и насчет этих библиотек ,нужны они или нет? 3)Также по информации вроде как нужны sumbol библиотеки DEBUG- Options and Sеttings скачиваются прямо из этого же меню,устанавливаются сами |
Да это я читал. рилмд пусть прямо во время компила будет запущен из рабочей папки серва (редко его дебажат), а в папку, откуда будет запускаться только что скомпиленный серв, туда только конфиг.
|
Цитата:
realmd - start то дебажится будет именно mangosd ,а реалмд будет просто запущен единственное тут тоже нужно указывать рабочую папку в конфигурации realmd Не знаю как лучше - это просто как вариант |
А "налету" в дебаге код нельзя менять?
А то я тут задолбался выискивая тормозящие строчки ради одной строки пересобирать мангос и запускать его =( |
Я так обычно и делаю.:)
Цитата:
|
Текущее время: 09:22. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS