Code::Blocks + gdb + gcc - в отладке видеть исходники оператора new
Коллеги помогите ссылкой или советом!
Отлаживаю программу (среда Code::Blocks 10, gdb 7, gcc 4.4.5), получаю ошибку сегментирования при вызове оператора new... Примерный код такой
Я понимаю, что в моей программе ошибка работы с памятью. Комментирование половины программы решает проблему, указанный оператор не выдает ошибки. Но хочется увидеть почему гнушный оператор new выдает SIGSEGV при условии, что где-то еще я накосячил.
Собственно вопрос. Как заставить указанный набор софта, который я использую для разработки, в отладчике попадать на отладку кода libstdc++?
Сижу под Gentoo, была идея пересобрать gcc в debug-режиме, но что-то не вижу подходящих use'ов, чтобы это пересобрать. Можно пересобрать libc в дебаг режиме, но судя по стеку, который я получаю, пока нужно добраться до исходников оператора new.
Вот собстенно стек (упрощенная до нельзя версия программы в целях локализации ошибки)
[ATTACH=CONFIG]5220[/ATTACH]
Пытался гуглить, но что-то запрос нормально не получается составить, чтобы получить то, что надо.
Спасибо
Отлаживаю программу (среда 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]
Пытался гуглить, но что-то запрос нормально не получается составить, чтобы получить то, что надо.
Спасибо
А на основании чего вы считаете, что ошибка внутри new? Как вы это поняли? Ну тоесть сам процесс опишите поиска ошибки. А так ошибка может быть и наведенной из-за кривого обращения к памяти ранее. Пробовали под валгриндом запускать?
а массив на миллион даблов не многоват ли? может память выделить не может?
Нет, не много. Это чуть меньше 8-ми мегабайт, что даже для 32-х разрядных систем мелочь.
А еслиб new не смог выделить, то все равно бы не было SIGSEGV.
А еслиб new не смог выделить, то все равно бы не было SIGSEGV.
Ошибка так и происходит. Останавливаюсь брейкпоинтом на указанном операторе, делаю next step и сразу получаю SIGSEGV, собственно приведнный стек и показывает, что валится malloc. И ничего в ответ уже не получаю. Основная причина мне более-менее понятна, где-то ломаю кучу предыдущей работой с динамической памятью, но вот докапаться бы...
Про валгринд... К своему стыду еще ниразу не пользовался подобными средствами, всегда аккуратно работал с динамической памятью, но вероятно пришло время. :) - спасибо за напоминание
Во всей ситации была надежда поймать проявление ошибки внутри new, и уже по указателям на память пытаться докапаться, где накосячил.
Но вероятно придется обратиться к _правильным_ инструментам, чтобы выудить причину.
Хотя, если кто еще подскажет как научиться отлаживаться с заходом внутрь stdlibc++ - буду благодарен.
Честно говоря даже обидно... Когда работал под Windows, Visual давал возможность заходить внутрь своей сишной бибилиотеки (дебаг версии библиотеки присутствовали), не думал, что это станет проблемой в Linux.
Про валгринд... К своему стыду еще ниразу не пользовался подобными средствами, всегда аккуратно работал с динамической памятью, но вероятно пришло время. :) - спасибо за напоминание
Во всей ситации была надежда поймать проявление ошибки внутри new, и уже по указателям на память пытаться докапаться, где накосячил.
Но вероятно придется обратиться к _правильным_ инструментам, чтобы выудить причину.
Хотя, если кто еще подскажет как научиться отлаживаться с заходом внутрь stdlibc++ - буду благодарен.
Честно говоря даже обидно... Когда работал под Windows, Visual давал возможность заходить внутрь своей сишной бибилиотеки (дебаг версии библиотеки присутствовали), не думал, что это станет проблемой в Linux.
Цитата: grgdvo
Во всей ситации была надежда поймать проявление ошибки внутри new, и уже по указателям на память пытаться докапаться, где накосячил.
Это не так то просто на самом деле. Гораздо проще найти реальное место, где портится память. Попробуйте валгринд - с большой вероятностью ошибку найдете быстро.
вам действительно нужна непострипанная версия libstdc++
Что-ж три дня гугления пока не дали результатов.
Дебаг версии 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.
Теперь буду всем рекомендовать
Дебаг версии 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.
Теперь буду всем рекомендовать
Нашлось наконец решение. Спасибо 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 можно убрать,
если, конечно, не хочется еще насобирать какой-то отладочной информации.
Всем спасибо. Тема закрыта.
Для потомков сухой остаток.
Пересобрал 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 можно убрать,
если, конечно, не хочется еще насобирать какой-то отладочной информации.
Всем спасибо. Тема закрыта.