LINUX.ORG.RU

Релизные билды и краш-дампы

 ,


0

1

Хотелось бы узнать как поступает большинство.

Вот допустим у пользователя случился краш. Собран краш-дамп. Этот дамп прислан разработчику. Но дело в том, что дамп собран с релизной версии. В свою очередь, эта релизная версия собрана без дебаг-инфы.

Я сейчас экспериментировал, намеренно заставил приложение падать. И собирал дампы с разных билдов. Исходный код одинаковый. Собрал релизный билд без дебаг-инфы (с него собрал краш-дамп) и релизный билд с дебаг-инфой. Ну и вот, вышло, что дамп собранный с одного билда не подходит к другому. GDB его открывает нормально, но неправильно показывает место краша.

Выход я вижу только один. Собирать релиз с дебаг-инфой, возможно выгруженной в отдельный файл. Но не вся инфа выгружается. Интересует бест-практик. Как вообще люди делают?

★★★★★
Ответ на: комментарий от hibou

Вот, а как сказать cmake'у не просто вырезать инфу, а собирать из нее отдельный пакет?

это не по части cmake-а, это дебовские утилиты умеют, к примеру

Harald ★★★★★
()
Ответ на: комментарий от hibou

Это не задача cmake. Это делает пакетный менеджер на этапе упаковки, своими силами, полностью автоматически, человек только должен проследить, что все бинарники компилятся с -g.

d_a ★★★★★
()
Ответ на: комментарий от hibou

Вот, а как сказать cmake'у не просто вырезать инфу, а собирать из нее отдельный пакет?

Это забота не CMake, а сборщика пакетов. В Debian (debhelper) в debian/rules добавляются строчки:

override_dh_strip:
        dh_strip $@ --dbg-package=package-dbg

и при сборке он генерирует package-dbg с нестрипнутыми бинарниками.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Это я тоже знаю. Но у нас генерируются 2 пакета, и rpm, и deb. И оба средствами cmake, а точнее cpack. И вот хорошо бы через него сделать.

hibou ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.