LINUX.ORG.RU

Памажите, люди добраи!!! (дебажить pthreads)


0

0

Почему-то на нормальные заголовки никто не откликается, может я что не так делал?

Вопрос такой - в Линухе пишу второй проект, и до этого удавалось
обходиться printf'ами. Ну логи до горизонта, что с того?
Однако сколь ни жаль, видимо кто-то у нас кран с памятью
забыл закрыть, и она течет. Плюс, в связи с этим или нет, раз в два
дня мой модуль повадился умирать смертью храбрых. Причем (редкостный
негодяй!), только в релизе, где дебажные принтфы отключены. Остается
корка, но чего с ней делать я ессно не ведаю.

Чего хочу-то?
Хочу дебажить это дело (runtime или post-mortem debug).
"Это дело" использует, и довольно активно (с динамикой), pthreads и
когда-нибудь потом (еще нескоро) начнет форкаться. Мое недалекое
окружение умеет худо-бедно single-thread дебажить, я и того не могу.

Очень желателен дебагер умеющий за памятью охотится (навроде boundscheker'a к msvc++). Пробовал прикручивать efence, но как-то
не очень вышло ввиду дремучего непонимания к чему собсно прикручивать.

Что взять, ап чем почитать?
Что лучше?


Insure++ спасёт отца русской демократии. Берётся сие чудо на www.parasoft.com. Но за деньги.

ДВ

anonymous
()

Спасибо, посмотрю.
А ишо?

Wotson
() автор топика

Ну по мне gdb вполне подходит...

Когда корка есть, используй gdb -c core program В общем info gdb ;)

Кстати - использование thread+fork -очень взрывоопасно;) Подумай очень хорошо.

tvn
()

2tvn:
thread+fork: поэтому и "очень нескоро". Некоторым деятелям просто
оч. нравится форкаться, и оч. не нравятся нити. Пока мы их давим...
(Тем более, это у них эстетические соображения похоже)

По поводу gdb -c core program: bt показывает, собачка, трейс
произвольной нити, в нашем случае вероятнее всего правильной.
Шанс угадать - 1/20. Угрюмо, а?
Или может я чего упустил опять?

Wotson
() автор топика

2 Wotson В принципе правильно, но вот мне кажется что не совсем - когда образуется корка - то ядро снимает именно активную нить (в данном случае процес для ядра;) ), и за ним весь процесс. Поэтому при компиляции с ключем -g... -g3 и без оптимизации в корке всегда есть то что вызвало падение (говорим только о однопроцессорной тачке)

Хотя я могу и ошибаться, хотя на практике я не встречал чтобы корка не содержала места падения;) То что происходит segmentation fault, а корка в многонитеевой проге не генерится - это сколько угодно;) (Вопрос не в ulimits, etc, а именно в нитях;) )

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