Добрый день.

Поставляем пользователям программу написанную на native C++.
Во время поставок не сохранили PDB файлы для библиотеки Qt.

Сейчас, при получении инфромации о вылетах (минидампов) от пользователей, стек в районе Qt-шных вызовов не восстанавливается (ни WinDBG, ни Visual Studio).

Может кто нибудь подскажет как восстановить pdb фалы (интернет говорит что похоже никак, при компиляции генерируются GUIDы)?
Если и в самом деле нельзя восстановить, то может можно к.л. заставить отладчик использовать аналогичный pdb файл? Ведь исходные коды есть, компилятор есть. Мы можем скомпилировать всё, что угодно (кроме нужных pdb ).

С уважениме, Сергей.

Здравствуйте, P_YegreS_P, Вы писали:

P_Y>Добрый день.

P_Y>Поставляем пользователям программу написанную на native C++.
P_Y>Во время поставок не сохранили PDB файлы для библиотеки Qt.

P_Y>Сейчас, при получении инфромации о вылетах (минидампов) от пользователей, стек в районе Qt-шных вызовов не восстанавливается (ни WinDBG, ни Visual Studio).

P_Y>Может кто нибудь подскажет как восстановить pdb фалы (интернет говорит что похоже никак, при компиляции генерируются GUIDы)?
P_Y>Если и в самом деле нельзя восстановить, то может можно к.л. заставить отладчик использовать аналогичный pdb файл? Ведь исходные коды есть, компилятор есть. Мы можем скомпилировать всё, что угодно (кроме нужных pdb ).

P_Y>С уважениме, Сергей.

А зачем Вам pdb? нам всегда было достаточно .map и потом .cod файлов. В большинстве случаем либо сразу видна ошибка либо понятно что и ничего не понятно и даже pdb не помогут.

S>А зачем Вам pdb? нам всегда было достаточно .map и потом .cod файлов. В большинстве случаем либо сразу видна ошибка либо понятно что и ничего не понятно и даже pdb не помогут.

что такое .cod файлы?

.map файлы позволяют определить только место вылета, но не стек к нему приводящий. Стек дает на порядок больше информации...

P_YegreS_P wrote:

> S>А зачем Вам pdb? нам всегда было достаточно .map и потом .cod файлов.
> В большинстве случаем либо сразу видна ошибка либо понятно что и ничего
> не понятно и даже pdb не помогут.
>
> что такое .cod файлы?

Грубо говоря, это те же PDB, но в другом формате.

PDB -файлы восстановить нельзя, можно только собрать заново вашу программу,
с PDB.

Здравствуйте, P_YegreS_P, Вы писали:

P_Y>что такое .cod файлы?

Это файлы с кодом на асм соответствующие Вашим исходникам. По ним можно легко определить строчку падения.

P_Y>.map файлы позволяют определить только место вылета, но не стек к нему приводящий. Стек дает на порядок больше информации...
Стэк показывает Dump файл, точнее адреса функций в стэке. По мапу находите сами названия функций и смещение в конкретной функции. Ну а дальше по .cod файлам находите строчку крэша. Итого есть стэк, функция в которой упало и строчка в которой упала. + В дамп файле есть тип ошибки. ИМХО, этого достаточно.

Здравствуйте, szag, Вы писали:

S>Стэк показывает Dump файл, точнее адреса функций в стэке. По мапу находите сами названия функций и смещение в конкретной функции. Ну а дальше по .cod файлам находите строчку крэша. Итого есть стэк, функция в которой упало и строчка в которой упала. + В дамп файле есть тип ошибки. ИМХО, этого достаточно.

а подробнее вы можете пояснить способ анализа дампа?
какими тулзами следует пользоваться?
как дамп файл "показывает" стэк?
как по мапу найти название функции?
я надеюсь, это не вручную делается?

Здравствуйте, uzhas, Вы писали:

U>а подробнее вы можете пояснить способ анализа дампа?
U>какими тулзами следует пользоваться?
U>как дамп файл "показывает" стэк?
U>как по мапу найти название функции?
U>я надеюсь, это не вручную делается?

Я надеюсь свзяку dmp + pdb + исходники вы знаете?

А про map + cod мне и самому интересно очень...

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, szag, Вы писали:

S>>Стэк показывает Dump файл, точнее адреса функций в стэке. По мапу находите сами названия функций и смещение в конкретной функции. Ну а дальше по .cod файлам находите строчку крэша. Итого есть стэк, функция в которой упало и строчка в которой упала. + В дамп файле есть тип ошибки. ИМХО, этого достаточно.

U>а подробнее вы можете пояснить способ анализа дампа?
U>какими тулзами следует пользоваться?
U>как дамп файл "показывает" стэк?
U>как по мапу найти название функции?
U>я надеюсь, это не вручную делается?

Есть разные тулзы для этого. Watson dump viewer или WinDBG например.
Общая схема такова:
1. открываете дамп файл и смотрите информацию о процессе в котором произошла ошибка
что-то типа вот этого там должны увидеть:

Flags: 0x0008
Owner Process: 0x054B0006 ( yourprocess.EXE)
Current Process: 0x054B0006 ( yourprocess.EXE)
Thread: 0x054C0006 ( yourprocess!4003C188 )
API Owner Process: 0x00000000
API Current Process: 0x00000000
API Thread: 0x00000000
Exception Code: 0xC0000005
Exception Flags: 0x00000001
Address of Exception Record: 0x00000000
Exception Address: 0x0053CF4C
Exception Parameters:

2. Дальше открываем информацию о потоках этого процесса и ищем поток с InfoStatus == 0
3. Смотрим стэк этого потока, будет что-то вроде:

Function ReturnAddr FramePtr ProcessId Flags Params0 Params1 Params2 Params3
yourprocess!0053CF4C() 0053CF4C 00ACB2B4 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00063A9C() 00063A9C 00ACB2B8 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00183A00() 00183A00 00ACB2C0 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00543088() 00543088 00ACC260 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!003F7F5C() 003F7F5C 00ACC2B0 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00541648() 00541648 00ACC2EC 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!0038AAB8() 0038AAB8 00ACC314 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!0038AB98() 0038AB98 00ACC328 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!0051E9A8() 0051E9A8 00ACC334 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00177CB8() 00177CB8 00ACC368 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00348624() 00348624 00ACFDB0 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!00348690() 00348690 00ACFDD0 054B0006 00000000 00000000 00000000 054C0007 00000001
yourprocess!4003C188() 4003C188 00ACFDE4 054B0006 00000000 00000000 00000000 054C0007 00000001

4. Это и есть стэк. Вас интересует ReturnAddr здесь.
5. Есть такой бесплатный тул называется Exception Wizard. Работает он так, вы ему даете мап файл и указываете смещение, а он вам показывет имя функции. Итого, по адресам выше легко восстанавливается стэк.
6. Так же этот тул показывает Function offset в виде 0x74. Открываете соответствующий .cod файл и ищите эту функцию точно в том виде как дал Вам её Exception Wizard. Находите функцию и там будут идти смещения на каждую строку, по смещению находите строчку крэша.

Это если вкратце. А так тут конечно много нюансов.

Здравствуйте, P_YegreS_P, Вы писали:

P_Y>Я надеюсь свзяку dmp + pdb + исходники вы знаете?
с этой связкой знаком и с ней работают windbg\studio, но в исходном сообщении сказано, что родного pdb нет
поэтому мне тоже интересно как изучать дамп без родного pdb

Здравствуйте, szag, Вы писали:

S>4. Это и есть стэк.
Спасибо, я боялся увидеть такой стек=)
Стек интересно видеть полностью, без рутинной работы (кстати, деманглинг имен тулза делает?).
К примеру, в дампах очень часто анализирую все потоки, а их бывает очень много.
В стеке еще интересны типы и значения аргументов (бывает ноль передаешь куда-то, а функция падает от этого)
Интересно было бы более виндузятный подход увидеть =) Когда все как на ладони

Здравствуйте, szag, Вы писали:

S>Есть разные тулзы для этого. Watson dump viewer или WinDBG например.
S>Общая схема такова:
...
S>3. Смотрим стэк этого потока, будет что-то вроде:
S>[q]
S> Function ReturnAddr FramePtr ProcessId Flags Params0 Params1 Params2 Params3
S>yourprocess!0053CF4C() 0053CF4C 00ACB2B4 054B0006 00000000 00000000 00000000 054C0007 00000001
S>yourprocess!00063A9C()
S>4. Это и есть стэк. Вас интересует ReturnAddr здесь.

Я всегда думал, что для корректного разворачивания стека и нужны .pdb файлы.
Интерсно, подойдут ли для этой цели map файлы?


Ну и попутно вопросы. А можно ли достать map файлы для системных библиотек? Можно ли их использовать совместно с pdb? (Но это больше вопросы не к вам, а к гуглу. Направление поиска понятно).

Попробуйте в windbg так:
.reload /f /i имя_модуля

собственно, опция i должна заставить windbg не обращать внимание на несовпадения pdb и крешдампа ( что за pdb хочет анализатор крешдампа можно узнать с помощью !chksym ). Если исходники точно те же и компилятор то же — может прокатить.

Здравствуйте, P_YegreS_P, Вы писали:
вы попробовали? работает?
самый удобный способ

Попробуйте в windbg так:
.reload /f /i имя_модуля

-берете из репозитария по лейблу исходники, из которых тогда собирали
-собираете из них новые бинари
-сравниваете новые бинари со старыми — отличия должны быть чисто косметическими
-хачим пдбшники от новых бинарей чтобы они к старым цеплялись, там по идее только црц\таймстэмп

а вся эта возня с восстановлением стека вручную без пдб — выброс времени

Здравствуйте, rm822, Вы писали:

R>-берете из репозитария по лейблу исходники, из которых тогда собирали
R>-собираете из них новые бинари
R>-сравниваете новые бинари со старыми — отличия должны быть чисто косметическими
R>-хачим пдбшники от новых бинарей чтобы они к старым цеплялись, там по идее только црц\таймстэмп

R>а вся эта возня с восстановлением стека вручную без пдб — выброс времени

Не соглашусь с Вами. Самое плохое в Вашем предложении — это отсутствие каких либо гарантий что pdb и dump файлы будут совместимы. Согласитесь, не хотелось бы разбираться не с тем стэком. В Вашем случае, увидя невалидный стэк будет совершенно не понятно, действительно ли он был испорчен к моменту крэша или это результат "кривых" pdb файлов.
У меня восстановление стэка по дампу и мап файлу занимает около 1 минуты, так ли это долго?
2 бинарника собранные на разных компьютерах могут отличаться, могут отличаться и map файлы, соответственно и адреса функций в стэке. Поэтому у нас есть правило — к каждому релизу выкладывать .map файл, в подавляющем большинстве случаев этого достаточно для нормального анализа dump файла и нахождения ошибки.

Здравствуйте, rm822, Вы писали:

R>-хачим пдбшники от новых бинарей чтобы они к старым цеплялись, там по идее только црц\таймстэмп

А можно вот тут по-подробнее. Как это делать?

R>>-хачим пдбшники от новых бинарей чтобы они к старым цеплялись, там по идее только црц\таймстэмп
R>А можно вот тут по-подробнее. Как это делать?
конечно

матч идет по гуиду


тулзу для приведения их к общему качаем отсюда
http://www.debuginfo.com/tools/chkmatch.html

если хочется деталей, то читай вот эту статью
http://www.debuginfo.com/articles/debuginfomatch.html

Здравствуйте, szag, Вы писали:

S>А зачем Вам pdb? нам всегда было достаточно .map и потом .cod файлов. В большинстве случаем либо сразу видна ошибка либо понятно что и ничего не понятно и даже pdb не помогут.
А значения локальных переменных чем смотреть? Руками stack frame пересчитывать?