LINUX.ORG.RU

каким таким? гдб работает на любой программе

anonymous
()

Совсем не понял, что значит «голый gdb» и какие должны быть приёмы. Компилирую g++ -g ..., после, при необходимости, отладка в gdb. Всё работает как должно.

Hasek ★★
()

Первым делом берешь и ставишь pretty printer для C++ std::*. Его можно взять, например, из QtCreator. Как прикручивать - легко гуглится.

anonymous
()

layout src очень помогает. А вообще предпочитаю не использовать отладчик. Имхо, проще assert и отладочная печать. А gdb — максимум, backtrace в корке посмотреть.

JaneDoe
()
Ответ на: комментарий от JaneDoe

А вообще предпочитаю не использовать отладчик. Имхо, проще assert и отладочная печать.

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

hotpil ★★★★
()

Обычно использую морду типа qtcreator'оа или nemiver'a и дополняю коммаендной строкой для анализа, типа «p someObj.someMethod()» и т.п.

invy ★★★★★
()

Приём один - gdb <path to binary>, run, bt full. В 90% этого достаточно, в оставшихся 10% нужно ещё пару переменных посмотреть. Больше ни за чем отладчик не нужен, ни для своего, ни для чужого кода.

slovazap ★★★★★
()

А где изврат?

break, watch, continue, step и всё такое.

Интересно, как милорд планирует дебажиться не у себя на рабочей тачке.

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

Я хочу автоматизации.

Например, есть корка, в ней есть десять очередей. В каждой очереди n обьектов разных типов, с разными родителями (или не с разными).

Хочется иметь такой функционал: накропать на колене скриптец, который пройдётся по всем очередям и выведет заданную инфу по произвольным обьектам.

Хочется уметь это делать легко и непринуждённо.

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от jcd

Для дебага не у себя на рабочей тачке бог придумал gdbserver.

А я хочу дополнительных плюшек по сравнению с gui.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от slovazap

Очень спорный вопрос. Бывают сложные системы со сложным состоянием.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от Hasek

Пока ты компилируешь g++ -g скорее всего твоя система слишком проста что бы вообще её отлаживать надо было :)

pon4ik ★★★★★
() автор топика

Есть кто-то занимающийся таким извратом?

Обычно оно проще и внятнее чем «gdb интегрированный в $IDE_NAME» :) В $IDE_NAMEах gdb может молча и внезапно умереть :)

Поделитесь списком основных приёмов.

bt по крэшдампу :)

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

bt наше всё, спору нет. Однако, иногда хочеться обозреть картинку, да ещё и погрепать её :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от slackwarrior

Это обычно происходит, когда ковыряешься в чьей то масштабной поделке с метапрограммированием, type erasure и потоками.

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

Pretty printers - поставил официальные, gdb'шные.

Если это то, что я думаю, то оно старое и не умеет в С++11.

anonymous
()
Ответ на: комментарий от anonymous

У меня старый кодебейз, он тоже не умеет в c++11 :)

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

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

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

Для дебага не у себя на рабочей тачке бог придумал gdbserver.

... к которому подключаются через ... ?

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

А я хочу дополнительных плюшек по сравнению с gui.

Это врядли, нужно рассматривать конкретный фронтенд.

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

Через gdb или любой вменяемый фронтэнд. Возможно я просто не понял суть твоего предыдущего высказывания.

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

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

Для этого же вроде как раз придумали логирование на уровне исходного кода, когда никакие отладчики не нужны.

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

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

anonymous
()
Ответ на: комментарий от pon4ik

Аля пройтись по всем потокам, посмотреть на имя потока, прыгнуть в нужный фрейм, распечатать состояние

это все умеет gdb ручками, пару команд

anonymous
()
Ответ на: комментарий от anonymous

Кому то не нужна. Мне нужна.

а чтение и понимание всех сорсов надо начинать до компиляции

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

pon4ik ★★★★★
() автор топика

Я, всё нормально работает

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

В терминах того про что gdb знает - несомненно. threads apply all и всё такое, а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

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

а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

Я думаю, что всё это и больше можно сделать через Guile или Python API.

Как оно?

Нормально. Недавно нашёл как не заходить в inline функции стандартной библиотеки по step (тут внизу).

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

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

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

anonymous
()
Ответ на: комментарий от pon4ik

threads apply all и всё такое, а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

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

anonymous
()
Ответ на: комментарий от xaizek

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

В чем разница между guile и python api?

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Мне первый раз потребовалось. Ну, или скорее захотелось.

У меня условие не для стейта в памяти, а для номера потока.

Просто хочется в n временных точек распечатать картину мира с теми деталями которые нужны для осознания что пошло не так.

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ну, то что ты ужасно крут и обозреваешь такие вещи во всех деталях(в которых дьявол кроется) одним взором это я уже понял :)

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

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

anonymous
()
Ответ на: комментарий от pon4ik

В чем разница между guile и python api?

У них написано:

Guile support in gdb follows the Python support in gdb reasonably closely, so concepts there should carry over. However, some things are done differently where it makes sense.
Так что особой разницы по функциональности быть не должно, просто Guile это официальный язык расширения для GNU-проектов, а Python более популярен, видимо, поэтому и два интерфейса.

xaizek ★★★★★
()

Оно примерно как работа в обычной консольке, только хуже (слишком тупые автокомплит и повторение последней команды по вводу) но есть ещё всякие плюшки в виде pretty printer-ов и возможности писать скрипты на питоне. В большинстве обхожусь коробочным вариантом и на случаи копания в адских корках за годы накодил себе небольшой инструментик автоматизации этого процесса на питоне.

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

просто Guile это официальный язык расширения для GNU-проектов

Интересный факт, не знал, спасибо :)

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

Это обычно происходит, когда чью-то масштабную поделку жадные манагеры отдали на сапорт пионерам... А кто-то из их руководятлов вспомнил, что ты немного помогал автору поделки, который уже где-то делся по тихой грусти, а пионеры отломили все, что не поняли, как работает (типа автособиралки зависимостей созданой беглым пахарем с галеры в качестве дембельского аккорда, из-за чего специальный землекоп занят очень важным делом — понять как собирать это чудо), и рванулись чинить вообще ни разу не сломаное, допуская «интересные косяки» типа внезапного выделения памяти на пол-гига (и в замапленый файл тоже внезапно валится пол-гига... нулей :))

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

Ну всё немного тоньше, но смысл верный. С тех пор как россияне стали самыми дешёвыми индусами, у многих взыграла жадность.

Хотя, конкретно для меня это только в плюс, проект интересный хоть и замороченный слегка, учитывая, что до этого, люди там сидели годами и некоторые вещи делали в спешке, надо разбираться как оно работает.

У меня пока что нет задачи разобраться почему оно не работает(это обычно в разы проще), есть задача разобраться, почему, иногда, при определённом стечении обстоятельств оно работает не так хорошо как могло бы :)

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от mashina

А чего есть в инстументе? И есть ли оно в открытом виде?

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от anonymous

уровень размера сыцов линукс ядра или куте фреймворка это много? по моему средне

хрен с ним с Qt, там ничего ценного, плюсы и STL кругом. по содержанию код жиденький. но вот кернел не надо недооценивать. работая с ним несколько лет довольно плотно, я знаю далеко не все его особенности и даже не все подсистемы (только те, которые нужны в работе). подозреваю, что изучить весь кернел со всеми тонкостями маловероятно. даже если задаться такой целью специально. а он ещё и постоянно меняется.

я видела много проектов, которые по объёму кода формально больше кернела. но по сложности ничего даже близко.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

это зело улыбнуло. к сожалению, иногда оно так и бывает. хорошо ещё, если связь с оригинальным автором системы не потеряна окончательно. приходилось видеть искорёженный код, который от недопонимания и нехватки программистского опыта превращали из стройной системы в жуткие заросли костылей. видела кроссплатформу, убитую по незнанию виндузяцкими апи, прилепленными абы куда последующими разработчиками. поэтому лучше всего составлять некие хотя бы краткие описания архитектуры софта, чтобы последующим суппортам было не так страшно и они с испугу не начали бы испускать тонны говнокода. а сложные и неявные с первого взглядя куски кода лучше снабжать подробными комментариями прямо в коде. чтобы кривые руки не тянулись там что-то «исправлять».

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от pon4ik

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

кстати, есть офигенное средство для анализа всякой такой шняги. правда, код закрытый и оно небесплатное. но нарыть старые версии, которые раньше были бесплатны для опенсорца, в сети, наверное, можно. Intel Parallel Studio. там есть очень детальные и очень графически наглядные профайлеры, всякие анализаторы кода, отладчик (правда, под icc, но обычно это проблем не вызывает, он с gcc практически на 100% совместим по параметрам). вещь хорошая. в принципе, стоит не так уж дорого для частного использования, если очень нужно.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

Тыкать в каждый элемент n-сотенной хотя бы очереди, довольно таки не удобно.

Снятие дампа с помощью кода во время работы, довольно занимательное занятие, и с 90% вероятностью нивелирует конкретно это проблему и, скорее всего испортит картинку. А вот то что снимается gcore, подозрительно похоже на правду.

Хочется просто иметь возможность такие дампы красиво распечатывать написав минимум кода.

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

остановка софтин, работающих в риалтайме с очередями, обычно разрушает их нормальную работу. тут лучше профилировать чем-то лёгким, что не будет мешать работе и искажать статистику. для начала просто gprof натрави и посмотри, где стоит копать. потом попробуй mutrace, например. там видно затыки с локами.

снять стектрейс недолго. это не разрушит работу. а зачем дампы печатать? (пардон, вдруг вспомнился случай на огромной машине Hitachi, которая стояла в одном ВЦ. кто-то сдуру нажал вывод дампа на принтер. и принтер за несколько часов усиленной печати наполнил огромный машинный зал бумагой с этим дампом :) бумага была в таких складчатых стопках, с перфорацией по краям, но когда на неё печатали, она из принтера вылезала как попало. я зашла в машинный зал и увидела там бумагу до потолка).

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

с очередями, обычно разрушает их нормальную работу.

проблема проявляется довольно длительный момент времени.

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

Есть мнение, что при определённом стечении обстоятельств, имеет место быть ситуация, когда поток данных таков, что один или несколько родителей заблокированны на запись статистически в те моменты, когда на подходе свежие детки в большом числе, и соответсвенно, не могут получать детей. А к тому моменту, как очередь переходит к следующему родителю, его тоже ожидает множество детей, а он заблокирован. Дети живут в одной из очередей, и, если не удалось подцепить дитя к родителю, перекладываются в хвост. Соответсвенно, когда ситуация повторяется n раз за момент времени, очередь начинает расти. Чем больше очередь, тем больше шанс нарваться на заблокированного родителя и потратить время на переброс в хвост. А т.к. порядок не меняется, сиё действо заходит в цикл. По одному два элемента конечно убирается но подавляющее большинство просто постоянно тасуется с головы в хвост.

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

а зачем дампы печатать

Случай про машину улыбнул :) Но я говорил про печать в стандартный выход, с целью сделать grep | sort | uniq.

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

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

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

Про инструмент слышу впервые. Спасибо, потыкаю :)

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

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

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