Как при наличии отладочных символов только своей dll получить её переменные из дампа памяти приложения?

#visual_studio #dll #отладка #dump

Есть моя DLL библиотека (проект Visual Studio 2013). Ее используют чужие программы.
Во время работы этих программ было сохранено несколько полных дампов память процессов
этих программ.
Я открываю эти дампы в моем Visual Studio проекте. Отладочные символы я имею только
для моей DLL. При этом, если во время сохранения дампа исполнялся код одной из функций
моей DLL, то видно все символы в исходном коде, место текущего исполнения итд. Но если,
исполнялся другой код, я никаких данных не вижу и посмотреть текущее значение переменных
моей DLL не могу. Локальные переменные ясное дело недоступны, так как их нет, но и
статические данные тоже не видны.  

Как просматривать данные моей DLL?
    

Ответы

Ответ 1

Не уверен, можно ли это сделать через студию. Но точно можно через WinDBG:


Открыть дамп.
Включить ссылки в выводе:

.prefer_dml 1

Прописать путь к символам:

.sympath+ srv*

Загрузить SOS (пусть исправить на соответствующий версии и платформе)

для 4.0:

.loadby sos clr


для <4.0

.loadby sos mscorwks 


или по полному пути

.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll

Найти EEClass для того типа, для которого хочется посмотреть статические поля

> !name2ee mscorlib.dll System.Console
Module: 0000064278854000 (mscorlib.dll)
Token: 0x000000000200008b
MethodTable: 00000642788c8d10
EEClass: 0000064278a271a8
Name: System.Console

Посмотреть статические поля:

> !dumpclass 0000064278a271a8
Class Name: System.Console
mdToken: 000000000200008b (C:\WINDOWS\assembly\GAC_64\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Parent Class: 00000642788c0c30
Module: 0000064278854000
Method Table: 00000642788c8d10
Vtable Slots: 4
Total Method Slots: 78
Class Attributes: 100181  Abstract, 
NumInstanceFields: 0
NumStaticFields: d
MT    Field   Offset                 Type VT     Attr            Value Name
00000642788f5aa0  40002ae       d8 System.IO.TextReader  0   shared           static _in



Дальше перемещаться кликами по адресам объектов - в режиме DML по клику будет выполнятся
соответствующая команда для дампа объекта. 

По настройке WinDBG есть отличный мануал Debugging Managed Code Using the Windows
Debugger.

Почему не всегда записывается дамп ядра?

#linux #dump

На определённом хосте иногда падает один процесс, поэтому для него была включена
запись дампов ядра. Один раз дамп записался, но с тех пор было ещё три падения — дампов нет.



$ cat /etc/security/limits.conf | grep core | grep -v '#'
*    -    core    unlimited

$ cat /proc/sys/kernel/core_pattern
/tmp/core.%e.%p.%h.%t

$ ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 2063246
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2063246
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ cat /proc/$(pgrep myprocess)/limits | grep core
Max core file size        unlimited            unlimited            bytes


Свободного места достаточно (около 17Gb, дамп занимает 2-4 Gb). Вручную процесс никто
не останавливал. О том, что было именно падение, я сужу по логам:

monit:

[NOVT Feb 12 05:07:21] error    : 'myprocess' process is not running
[NOVT Feb 12 05:07:21] info     : 'myprocess' trying to restart
[NOVT Feb 12 05:07:21] info     : 'myprocess' start: /etc/init.d/myprocess
[NOVT Feb 12 05:09:21] info     : 'myprocess' process is running with pid 22233


nginx, который направляет запросы этому процессу (оставил только нужное). Видим,
что в 05:06:20 уже вернул 502.

1.2.3.4 myhost - [12/Feb/2016:05:05:49 +0600] "POST someurl" 200 2659 ...
1.2.3.4 myhost - [12/Feb/2016:05:05:49 +0600] "POST someurl" 200 933 ...
1.2.3.4 myhost - [12/Feb/2016:05:06:20 +0600] "POST someurl" 502 166 ...


Я специально тестировал и убедился, что на точно такой же конфигурации дампы ядра
пишутся, в том числе когда уже есть один дамп (использовал kill -SIGSEGV pid). UPD:
протестировал прямо на этом хосте: дамп пишется.

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

Вопросы:


Может ли процесс в linux как-то аварийно завершить работу, чтобы это не попало под
условия, в которых не инициализируется дамп?
В чём ещё может быть причина, куда копать, что исследовать?

    

Ответы

Ответ 1

Из комментария @o2gy:

Может там в процессе где-то срабатывает return/exit? Core dump нету, вот и итоговый
дамп не создаётся.

Когда правильнее делать дамп MySQL?

#mysql #база_данных #dump

Есть курсовая работа. Тема курсовой работы "Автоматизированная система ЗАГС". Ну
можно сказать работу я закончил, но так как данные ЗАГСа очень важны, вот я и решил
написать скрипт который сделал бы dump базы данных.

Когда правильнее делать dump? Может каждый час или после каждого рабочего дня или
может после каждого изменения в базе данных?
    

Ответы

Ответ 1

Есть два варианта, которые вам стоит рассмотреть, если вы хотите обеспечить сохранность
вашей базы данных.


Действительно, делать бекап базы данных. Частоту выбирать согласно тому, насколько
проблемно реально потом будет восстановить данные руками либо вашими, либо персонала,
введенные за текущий / предыдущий день. Но имейте ввиду, что дамп подразумевает остановку
работы с базой.
Настроить репликацию, которая позволит иметь копию базы данных на момент отказа основного
сервера. Руководств в сети полно, ищутся по запросу mysql репликация.


Естественно, что при желании вы можете и совместить их. При этом в случае совмещения
дамп можно делать на slave-сервере, в таком случае отпадет необходимость останавливать
работу с master-сервером.


Ответ 2

Обычно для значимых данных используют комбинацию из нескольких способов:


Бэкап базы данных. Для важных данных делают ежедневно (точнее каждую ночь, когда
меньше нагрузка на базу). А в случае ЗАГСа это еще лучше, т.к. там ночью не будет никаких
изменений базы.
Для данных, которые поступают уже после крайнего бэкапа лучше использовать временное
хранилище. Т.е. при записи данных, они пишутся в основную базу и временное хранилище.
Сразу после ночного бэкапа временное хранилище очищается. Репликацию использовать нужно,
но она предназначена немного для другого. При падении базы да, она спасает ситуацию,
но в случае неверной записи или преднамеренного изменения/удаления данных она перезапишет
изменения в копии базы и информация будет безвозвратно удалена.

Как при наличии отладочных символов только своей dll получить её переменные из дампа памяти приложения?

Есть моя DLL библиотека (проект Visual Studio 2013). Ее используют чужие программы. Во время работы этих программ было сохранено несколько полных дампов память процессов этих программ. Я открываю эти дампы в моем Visual Studio проекте. Отладочные символы я имею только для моей DLL. При этом, если во время сохранения дампа исполнялся код одной из функций моей DLL, то видно все символы в исходном коде, место текущего исполнения итд. Но если, исполнялся другой код, я никаких данных не вижу и посмотреть текущее значение переменных моей DLL не могу. Локальные переменные ясное дело недоступны, так как их нет, но и статические данные тоже не видны.
Как просматривать данные моей DLL?

Ответ

Не уверен, можно ли это сделать через студию. Но точно можно через WinDBG:
Открыть дамп. Включить ссылки в выводе:
.prefer_dml 1 Прописать путь к символам:
.sympath+ srv* Загрузить SOS (пусть исправить на соответствующий версии и платформе)
для 4.0:
.loadby sos clr
для <4.0
.loadby sos mscorwks
или по полному пути
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll Найти EEClass для того типа, для которого хочется посмотреть статические поля
> !name2ee mscorlib.dll System.Console Module: 0000064278854000 (mscorlib.dll) Token: 0x000000000200008b MethodTable: 00000642788c8d10 EEClass: 0000064278a271a8 Name: System.Console Посмотреть статические поля:
> !dumpclass 0000064278a271a8 Class Name: System.Console mdToken: 000000000200008b (C:\WINDOWS\assembly\GAC_64\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll) Parent Class: 00000642788c0c30 Module: 0000064278854000 Method Table: 00000642788c8d10 Vtable Slots: 4 Total Method Slots: 78 Class Attributes: 100181 Abstract, NumInstanceFields: 0 NumStaticFields: d MT Field Offset Type VT Attr Value Name 00000642788f5aa0 40002ae d8 System.IO.TextReader 0 shared static _in
Дальше перемещаться кликами по адресам объектов - в режиме DML по клику будет выполнятся соответствующая команда для дампа объекта.
По настройке WinDBG есть отличный мануал Debugging Managed Code Using the Windows Debugger.

Когда правильнее делать дамп MySQL?

Есть курсовая работа. Тема курсовой работы "Автоматизированная система ЗАГС". Ну можно сказать работу я закончил, но так как данные ЗАГСа очень важны, вот я и решил написать скрипт который сделал бы dump базы данных.
Когда правильнее делать dump? Может каждый час или после каждого рабочего дня или может после каждого изменения в базе данных?

Ответ

Есть два варианта, которые вам стоит рассмотреть, если вы хотите обеспечить сохранность вашей базы данных.
Действительно, делать бекап базы данных. Частоту выбирать согласно тому, насколько проблемно реально потом будет восстановить данные руками либо вашими, либо персонала, введенные за текущий / предыдущий день. Но имейте ввиду, что дамп подразумевает остановку работы с базой. Настроить репликацию, которая позволит иметь копию базы данных на момент отказа основного сервера. Руководств в сети полно, ищутся по запросу mysql репликация
Естественно, что при желании вы можете и совместить их. При этом в случае совмещения дамп можно делать на slave-сервере, в таком случае отпадет необходимость останавливать работу с master-сервером.