Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »

Почтовая рассылка

Подписчиков: 6302
Последний выпуск: 19.06.2015

Code::Blocks + gdb + gcc - в отладке видеть исходники оператора new

411
11 июля 2011 года
grgdvo
323 / / 04.07.2007
Коллеги помогите ссылкой или советом!

Отлаживаю программу (среда Code::Blocks 10, gdb 7, gcc 4.4.5), получаю ошибку сегментирования при вызове оператора new... Примерный код такой
 
Код:
double* ptr = new double[1000000];


Я понимаю, что в моей программе ошибка работы с памятью. Комментирование половины программы решает проблему, указанный оператор не выдает ошибки. Но хочется увидеть почему гнушный оператор new выдает SIGSEGV при условии, что где-то еще я накосячил.

Собственно вопрос. Как заставить указанный набор софта, который я использую для разработки, в отладчике попадать на отладку кода libstdc++?

Сижу под Gentoo, была идея пересобрать gcc в debug-режиме, но что-то не вижу подходящих use'ов, чтобы это пересобрать. Можно пересобрать libc в дебаг режиме, но судя по стеку, который я получаю, пока нужно добраться до исходников оператора new.

Вот собстенно стек (упрощенная до нельзя версия программы в целях локализации ошибки)
[ATTACH=CONFIG]5220[/ATTACH]

Пытался гуглить, но что-то запрос нормально не получается составить, чтобы получить то, что надо.

Спасибо
239
11 июля 2011 года
aks
2.5K / / 14.07.2006
А на основании чего вы считаете, что ошибка внутри new? Как вы это поняли? Ну тоесть сам процесс опишите поиска ошибки. А так ошибка может быть и наведенной из-за кривого обращения к памяти ранее. Пробовали под валгриндом запускать?
11
11 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
а массив на миллион даблов не многоват ли? может память выделить не может?
239
11 июля 2011 года
aks
2.5K / / 14.07.2006
Нет, не много. Это чуть меньше 8-ми мегабайт, что даже для 32-х разрядных систем мелочь.
А еслиб new не смог выделить, то все равно бы не было SIGSEGV.
411
11 июля 2011 года
grgdvo
323 / / 04.07.2007
Ошибка так и происходит. Останавливаюсь брейкпоинтом на указанном операторе, делаю next step и сразу получаю SIGSEGV, собственно приведнный стек и показывает, что валится malloc. И ничего в ответ уже не получаю. Основная причина мне более-менее понятна, где-то ломаю кучу предыдущей работой с динамической памятью, но вот докапаться бы...

Про валгринд... К своему стыду еще ниразу не пользовался подобными средствами, всегда аккуратно работал с динамической памятью, но вероятно пришло время. :) - спасибо за напоминание

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

Хотя, если кто еще подскажет как научиться отлаживаться с заходом внутрь stdlibc++ - буду благодарен.
Честно говоря даже обидно... Когда работал под Windows, Visual давал возможность заходить внутрь своей сишной бибилиотеки (дебаг версии библиотеки присутствовали), не думал, что это станет проблемой в Linux.
239
11 июля 2011 года
aks
2.5K / / 14.07.2006
Цитата: grgdvo

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


Это не так то просто на самом деле. Гораздо проще найти реальное место, где портится память. Попробуйте валгринд - с большой вероятностью ошибку найдете быстро.

14
12 июля 2011 года
Phodopus
3.3K / / 19.06.2008
вам действительно нужна непострипанная версия libstdc++
411
15 июля 2011 года
grgdvo
323 / / 04.07.2007
Что-ж три дня гугления пока не дали результатов.

Дебаг версии glibc и gcc собрал... Для гентушников это достачтоно просто оказалось: 1) добавляем в make.conf FEATURES="splitdebug" 2) пересобираем gcc и glibc 3) получаем /usr/lib[64]/debug где лежат файлы с отладочной информацией 4) убираем splitdebug

Теперь стало чуть проще... в стеке уже не вопросики, а нормальные имена функций, значит отладочную информацию gdb подхватывает, но source-level debugging в stdc++ так и не работает - собака. Пытался использовать FEATURES="installsources" и пересборка glibc и gcc, но что-то тоже не работает.

Вообщем, буду еще копать - если получится решить проблему, отпишусь для потомков.
Тема еще актуальна, кто подскажет решение - мои благодарности.

Да. и самое главное!!!
Большое человеческое спасибо за valgrind
Ошибка была найден за 10 минут, из которых 9 минут заняли время на сборку, установку и ознакомление с valgrind.
Теперь буду всем рекомендовать
411
27 июля 2011 года
grgdvo
323 / / 04.07.2007
Нашлось наконец решение. Спасибо mastepaner'у c gentoo.ru/forum

Для потомков сухой остаток.
Пересобрал gcc и glibc при следующих условиях:
1. в make.conf в CFLAGS добавить "-ggdb"
2. в make.conf добавить FEATURES="installsources splitdebug"
3. Использовать USE="debug" для glibc

# emerge glibc gcc

В результате получил /usr/lib64/debug и /usr/src/debug, где лежат отладочная информация и исходники.
gdb все это богатство теперь подхватывает на лету. После пересборки все изменения в make.conf можно убрать,
если, конечно, не хочется еще насобирать какой-то отладочной информации.

Всем спасибо. Тема закрыта.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог