Таким образом, я замечаю строго некорректное поведение, связанное с вызовами стандартных библиотечных функций внутри GDB. У меня есть следующая программа для иллюстрации:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]) {
char *s1 = "test";
char *s2 = calloc(strlen("test")+1,sizeof(char));
snprintf(s2,strlen("test")+1,"test");
printf("string constant: %lu\n", strlen(s1));
printf("allocated string: %lu\n", strlen(s2));
free(s2);
return 0;
}
При запуске из командной строки эта программа выводит только то, что вы ожидаете:
string constant: 4
allocated string: 4
Однако в GDB я получить следующий неправильный вывод из вызовов strlen ():
(gdb) p strlen(s1)
$1 = -938856896
(gdb) p strlen(s2)
$2 = -938856896
Я уверен, что это проблема с glibc, поставляемым с Ubuntu (я использую 10.10), но это серьезная проблема для тех из нас, кто проводит много времени в GDB.
Кто-нибудь еще испытывает такого рода ошибки?
Какой лучший способ исправить это? Собрать glibc из исходного кода? (Я уже использую версию GDB, созданную из исходного кода)
Это известная ошибка в eglibc. См. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594740
.Библиотека работает просто отлично. Программа сообщает правильное значение даже при запуске под GDB. Ошибка, по-видимому, заключается в том, что gdb вычисляет выражение и заставляет целевую программу вызывать функцию. Такое же поведение я наблюдаю и в 10.04. Странно, что p printf ("foo \ n") правильно печатает 4.
Кажется, что GDB сбит с толку, потому что strlen является встроенным. Если вы сделаете это:
int (* len) (char *) = strlen;
И затем получите gdb print len ("foo"), вы получите правильный результат.
Это последнее обновление, но...
Используйте функцию printf, чтобы обойти эту проблему. например вместо p strlen(var) использовать p printf(var) он напечатает длину строки var