Из-за такой опечатки:

int n;
sscanf(s.c_str(), "node: %llu", &n);

(где int — 32 бита, а из-за %llu sscanf читает 64)
программа падала (ошибка сегментации) в разных местах, пока не заметил эту строку. Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).

И еще, подскажите пожалуйста безопасный и простой аналог sscanf чтобы не думать о длине типа с поддержкой 64-битных целых чисел?

Благодарю.

Здравствуйте, Wody, Вы писали:

W>программа падала (ошибка сегментации) в разных местах, пока не заметил эту строку. Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).

W>Благодарю.
Я в таких ситуациях анализирую core dump.

Здравствуйте, Wody, Вы писали:

W>Из-за такой опечатки:
W>

W>int n;
W>sscanf(s.c_str(), "node: %llu", &n);
W>

W>(где int — 32 бита, а из-за %llu sscanf читает 64)
W>программа падала (ошибка сегментации) в разных местах, пока не заметил эту строку. Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).

W>И еще, подскажите пожалуйста безопасный и простой аналог sscanf чтобы не думать о длине типа с поддержкой 64-битных целых чисел?

W>Благодарю.

gcc при компиляции предупреждает о таких вещах.

Здравствуйте, Wody, Вы писали:

W>Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).
гуглить по ключевому слову "профайлер", гдб тут не при чем.

W>И еще, подскажите пожалуйста безопасный и простой аналог sscanf чтобы не думать о длине типа с поддержкой 64-битных целых чисел?
std::stringstream, boost::lexical_cast...

Здравствуйте, Аноним, Вы писали:
W>>Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).
А>гуглить по ключевому слову "профайлер", гдб тут не при чем.
А можно с этого места поподробнее?
Как с помощью профайлера можно найти подобную ошибку?
Я был уверен, что профайлер используется для совсем других целей...

Здравствуйте, Аноним, Вы писали:
W>>Подскажите, как с помощью gdb можно найти подобные ошибки (когда по неосторожности меняешь данные своей области памяти).
А>гуглить по ключевому слову "профайлер", гдб тут не при чем.
В данном случае не профайлер нужен, а valgrind

Здравствуйте, Tujh, Вы писали:


T>В данном случае не профайлер нужен, а valgrind
ближе к делу, но gdb + coredump удобнее и быстрее, ИМХО.

Здравствуйте, MaxGl, Вы писали:
MG>ближе к делу, но gdb + coredump удобнее и быстрее, ИМХО.
Может ошибусь, но gdb + coredump помогут если программа "упала", а если она "выжила" и работает с UB, то валгринд предпочтительней.
В любом случае прогнать через обоих не повредит

Здравствуйте, Tujh, Вы писали:

T>Может ошибусь, но gdb + coredump помогут если программа "упала", а если она "выжила" и работает с UB, то валгринд предпочтительней.
W> программа падала (ошибка сегментации) в разных местах
Она и падает. Но вот это "в разных местах" наводит на мысль, что падает она немного позже sscanf(), т.е. какое-то время работает с UB.
T>В любом случае прогнать через обоих не повредит
Согласен

Здравствуйте, Tujh, Вы писали:

А>>гуглить по ключевому слову "профайлер", гдб тут не при чем.
T>В данном случае не профайлер нужен, а valgrind

А разве valgrind умеет следить за памятью на стеке и сможет отловить такой случай?

Здравствуйте, kamre, Вы писали:

K>Здравствуйте, Tujh, Вы писали:

А>>>гуглить по ключевому слову "профайлер", гдб тут не при чем.
T>>В данном случае не профайлер нужен, а valgrind

K>А разве valgrind умеет следить за памятью на стеке и сможет отловить такой случай?
Нет: http://en.wikipedia.org/wiki/Valgrind#Limitations
Но все равно инструмент оччень полезный

Всем спасибо за ответы и ссылки.