[dev] manual debug

[partizanes]

Попробую сам описать по порядку все свои действия

Мануал рассчитан на аудиторию ,которая уже умеет на минимальном уровне работать с конфигурацией ,также имеет уже установленную базу данных ,и весь необходимый софт используемый в данном мануале ,включая исходники самого сервера.

Итак, Открываем проект с помощью visual studio (разбор идет на примере Visual studio 2010)

1) Выставляем режим Debug

(кажется этого хватает? )

2) Для того что бы запускать сервер прямо из студии(при условии отладки именно mangosd.exe )
устанавливаем проект по умолчанию mangosd

Примечание: Возможно можно еще и так -

3)Также по информации вроде как нужны sumbol библиотеки

DEBUG- Options and Sеttings
скачиваются прямо из этого же меню,устанавливаются сами

4)Устанавливаем рабочую папку (Working directory) [Для того что бы подхватывал *.conf файл ]

5)После Собираем Весь проект с помощью кнопки F7

6)Не Забываем положить в папку bin\Win32_Debug\

Примечание:
KiriX: Достаточно положить один конфиг, рилмд рапускать из рабочей папки сервера, а путь до ДБЦ и карт прописать в конфиге

a) файлы конфигурации mangosd.conf realmd.conf и по надобности scriptdev2.conf
(я думаю возможность отладки sd2 будет разобран чуть позже отдельно)

б)папки с dbc maps

в)Настроить конфигурационные файлы под себя (естественно тут уже как кому надо ,я допустим выставляю уровень вывода в консоль 3 и уровень записи в файл тоже 3

LogSQL = 3
PidFile = ""
LogLevel = 3

Остальные настройки тоже нужны выставлять для каждого определенного случая по разному ,что скрыть ,что то нет.

LogFile = "Server.log"
LogTimestamp = 0
LogFileLevel = 3
LogFilter_AchievementUpdates = 1
LogFilter_CreatureMoves = 1
LogFilter_TransportMoves = 1
LogFilter_VisibilityChanges = 1
LogFilter_Weather = 1
LogFilter_DbStrictedCheck = 1
LogFilter_PeriodicAffects = 0
LogFilter_PlayerMoves = 0
LogFilter_SQLText = 0
LogFilter_AIAndMovegens = 0
LogFilter_PlayerStats = 0
LogFilter_Damage = 0
LogFilter_Combat = 0
LogFilter_SpellCast = 0
WorldLogFile = ""
WorldLogTimestamp = 0
DBErrorLogFile = "DBErrors.log"
CharLogFile = "Char.log"
CharLogTimestamp = 0
CharLogDump = 0
GmLogFile = ""
GmLogTimestamp = 0
GmLogPerAccount = 0
RaLogFile = ""
LogColors = "2 7 11 9"

7)После проверяем запуская сервер из папки если прогрузка проходит удачно ,закрываем и запускаем из vs с помощью F5

Итак Когда все запустилось переходим к самому процессу отладки (всем огромное спасибо кто отписался в теме теперь вроде бы я понял как и что ,может быть не все ,но суть ясна)

Примечание: нас сейчас на данный момент интересует именно описанные в теме breakpointы, так вот их нужно расставлять в коде ,как будет разобрано чуть ниже.
Перекомпилировать не НУЖНО ,во время запущеного с vs сервера можно ставить и удалять брикпоинты . РАБОТАТЬ БУДЕТ

Разбирать будем по нескольким примерам:

Пример №1 (самый простой )

Находим в окошке проекта (Solution Explorer )

game - world/hadlers -battleground.cpp

открываем - ищем функцию (CTRL +F)

void BattleGround::SetBgRaid( uint32 TeamID, Group *bg_raid )

чуть ниже

old_raid = bg_raid;

Справа ставим брикпоинт с помощью левой кнопки мышки (вы сразу поймете если поставите ,большая красная точка)

Если нажать правой кнопкой мыши ,то можно выставить необходимые нам параметры для данного брикпоинта

чуть ниже в теме есть описание каждого из этих меню.

В самом низу есть вкладка BreakPoints ,она вам тоже понадобиться

Примечание :так как при запуске главным проектом является mangosd ,то естественно realmd (логин сервер не запускается) ,поэтому запускаем его вручную из папки .
Возможно можно еще и так -

далее заходим в игру под записью гм ,администратора
пишем в чате .debug bg
после нажимаем на клавишу H ,переходим на вкладку Поля боя -выбираем поле боя ,нажимаем вступить в бой -вступаем в бой

После всех этих действий должен сработать breakpoint ,вас или автоматически свернет на vs ,если этого не произошло свернитесь сами

Примечание:Как только срабатывает breakpoint весь мир замораживается ,и никакие действия происходить не будут!!! Для того что бы продолжить выполнение действий нужно в vs нажать F5 (Continue) (не спешите этого делать!)

После того как мы свернулись в vs -смотрим

Теперь при наведении на переменную видим значения этих переменных
Также обратите внимание как выглядит теперь красная точка.
Примечание:если вы обратили внимание то большинство значений 0 ,видимо по той простой причине что заход на бг,был произведен в дебаг режиме ,поэтому большинство значений просто не были нужны
После того как бы налюбовались и проверили значения ,убедились что в мире ничего не происходит .можно нажать кнопку F5 -и выполнение процесса продолжиться .

Пример №2






Всем спасибо за ответы.

[virusav]

Я делал таким образом (в 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 будет невозможна

[MaS0n]

Ну, во-первых, надо собирать все проекты в 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 - показывает все в ассемблерном коде

Ну вот и все, да, просмотреть вручную какие-то значения или данные можно, просто наведя мышку на нужный участок(переменная и т.д) при остановке и срабатывании бряка
Вот чем я обычно пользуюсь. Кому надо подробнее - гуглите)

[virusav]

Почему надо собирать ядро именно в debug-режиме, ведь отладка также работает и в release?

[Йоха]

Сообщение от virusav

Почему надо собирать ядро именно в debug-режиме, ведь отладка также работает и в release?

конечно, можно выставить дебаг опции в релизе и спокойно дебажить

[MaS0n]

И трассировка работает, и все вышеперечисленные свойства? Насколько я знаю, сборка дебаг содержит отладочную информацию, которая как раз и позволяет вычислять заничения переменных, отслеживать вызовы функций и т.д. Да и в IDA код проще смотрится) Если б близы собирали в дебаге....))

[zergtmn]

Если отключить всю оптимизацию (иначе отладчик VS будет глючить) и включить генерацию отладочной информации, то вполне можно и в релизе отлаживать. Но смысл?

[virusav]

Отладку всегда делаю в релизе, глюков не наблюдал.

[partizanes]

<reseved>

[zergtmn]

Сообщение от virusav

Отладку всегда делаю в релизе, глюков не наблюдал.

Стоит только включить оптимизацию...
http://img411.imageshack.us/img411/5412/gggoo.png

[KiriX]

Отличный мануал, всем спасибо.
Топикстартеру:
6)Не Забываем положить в папку bin\Win32_Debug\
Достаточно положить один конфиг, рилмд рапускать из рабочей папки сервера, а путь до ДБЦ и карт прописать в конфиге

[partizanes]

Путь к картам и дбц понятно,а вот насчет запуска реалмд ,наверно и так можно?
Примечание: Возможно можно еще и так -

и насчет этих библиотек ,нужны они или нет?
3)Также по информации вроде как нужны sumbol библиотеки

DEBUG- Options and Sеttings
скачиваются прямо из этого же меню,устанавливаются сами

[KiriX]

Да это я читал. рилмд пусть прямо во время компила будет запущен из рабочей папки серва (редко его дебажат), а в папку, откуда будет запускаться только что скомпиленный серв, туда только конфиг.

[partizanes]

Сообщение от KiriX

Да это я читал. рилмд пусть прямо во время компила будет запущен из рабочей папки серва (редко его дебажат), а в папку, откуда будет запускаться только что скомпиленный серв, туда только конфиг.

так вот в том то и вопрос..если поставить в конфигурации проекта - mangosd - start without debuging
realmd - start

то дебажится будет именно mangosd ,а реалмд будет просто запущен
единственное тут тоже нужно указывать рабочую папку в конфигурации realmd

Не знаю как лучше - это просто как вариант

[KiriX]

А "налету" в дебаге код нельзя менять?
А то я тут задолбался выискивая тормозящие строчки ради одной строки пересобирать мангос и запускать его

[virusav]

Я так обычно и делаю.

When Hit - когда бряк прокнулся, что-то сделать - например напечтать сообщение, исполнить макрос(подробнее ниже) или просто продолжить выполнение функции/процедуры/метода - как бы пропустив брекпойнт(не останавливая процесс/приложение)

Может, этот пункт можно использовать, хз.