Segfault при доступе к элементу структуры
Я столкнулся со странной проблемой, моя программа имеет ошибку при попытке доступа к элементу структуры, но адрес моей структуры не равен NULL, и я никогда не освобождаю эту структуру.
Адрес структуры - что-то вроде "0x8000000000" или "0x2000000000".
Вот БТД GDB:
Program received signal SIGSEGV, Segmentation fault.
0x00000001000039cc in ft_sort_ascii (files=0x8000000000000) at srcs/sort/ascii.c:43
43 while (i < files->len)
(gdb) bt
#0 0x00000001000039cc in ft_sort_ascii (files=0x8000000000000) at srcs/sort/ascii.c:43
#1 0x0000000100003a3c in ft_sort_ascii (files=0x10080a400) at srcs/sort/ascii.c:50
#2 0x0000000100003a3c in ft_sort_ascii (files=0x1001080d0) at srcs/sort/ascii.c:50
#3 0x0000000100003a3c in ft_sort_ascii (files=0x100801800) at srcs/sort/ascii.c:50
#4 0x0000000100003a3c in ft_sort_ascii (files=0x100801200) at srcs/sort/ascii.c:50
#5 0x0000000100003a3c in ft_sort_ascii (files=0x100104c10) at srcs/sort/ascii.c:50
#6 0x0000000100002137 in main (ac=1, av=0x7fff5fbff758) at srcs/main.c:26
Отчет Valgrind:
==29835==
==29835== HEAP SUMMARY:
==29835== in use at exit: 415,075 bytes in 11,152 blocks
==29835== total heap usage: 17,711 allocs, 6,559 frees, 3,960,490 bytes allocated
==29835==
==29835== 112 bytes in 1 blocks are definitely lost in loss record 106 of 178
==29835== at 0x10000CCA1: calloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x1004ABC11: class_createInstance (in /usr/lib/libobjc.A.dylib)
==29835== by 0x10010F920: _os_object_alloc_realized (in /usr/lib/system/libdispatch.dylib)
==29835== by 0x1004650D5: _xpc_pipe_create (in /usr/lib/system/libxpc.dylib)
==29835== by 0x100467655: xpc_pipe_create (in /usr/lib/system/libxpc.dylib)
==29835== by 0x1002AE100: _od_xpc_pipe (in /usr/lib/system/libsystem_info.dylib)
==29835== by 0x1002AE044: _od_running (in /usr/lib/system/libsystem_info.dylib)
==29835== by 0x1002ADFD8: ds_user_byuid (in /usr/lib/system/libsystem_info.dylib)
==29835== by 0x1002ADF46: search_item_bynumber (in /usr/lib/system/libsystem_info.dylib)
==29835== by 0x1002ADE82: getpwuid (in /usr/lib/system/libsystem_info.dylib)
==29835== by 0x1000029EB: ft_get_file_infos (in ./ft_ls)
==29835== by 0x1000027B4: ft_set_infos_foreach (in ./ft_ls)
==29835==
==29835== 121 bytes in 1 blocks are definitely lost in loss record 107 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== 405 bytes in 5 blocks are definitely lost in loss record 130 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== 516 bytes in 20 blocks are definitely lost in loss record 133 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835==
==29835== 2,523 bytes in 27 blocks are definitely lost in loss record 157 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== 6,124 bytes in 140 blocks are definitely lost in loss record 165 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== 6,493 bytes in 205 blocks are definitely lost in loss record 166 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002F6B: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100003061: ft_open_directories (in ./ft_ls)
==29835== by 0x10000276E: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== 341,832 (104 direct, 341,728 indirect) bytes in 1 blocks are definitely lost in loss record 178 of 178
==29835== at 0x10000C59B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==29835== by 0x100002474: ft_set_files (in ./ft_ls)
==29835== by 0x100002120: main (in ./ft_ls)
==29835==
==29835== LEAK SUMMARY:
==29835== definitely lost: 16,398 bytes in 400 blocks
==29835== indirectly lost: 341,728 bytes in 10,269 blocks
==29835== possibly lost: 0 bytes in 0 blocks
==29835== still reachable: 22,201 bytes in 62 blocks
==29835== suppressed: 34,748 bytes in 421 blocks
==29835== Reachable blocks (those to which a pointer was found) are not shown.
==29835== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==29835==
==29835== For counts of detected and suppressed errors, rerun with: -v
==29835== ERROR SUMMARY: 1243 errors from 14 contexts (suppressed: 21 from 21)
Кажется, у меня много ошибок / утечек, я не освобождаю свою память, которую я использовал один раз (все мои t_files), потому что они будут освобождены в конце программы.
И вот мой код:
static void ft_swap_files(t_files *files, size_t *i)
{
size_t j;
t_files tmp;
j = *i + 1;
while (j < files->len)
{
if (files[j].error < 0)
{
if (ft_strcmp(files[*i].name, files[j].name) > 0)
{
tmp = files[*i];
files[*i] = files[j];
files[j] = tmp;
*i = -1;
return ;
}
}
j++;
}
}
void ft_sort_ascii(t_files *files)
{
size_t i;
i = 0;
while (i < files->len)
{
if (files[i].error < 0)
{
ft_swap_files(files, &i);
if (files[i].files != NULL)
{
ft_sort_ascii(files[i].files);
}
}
i++;
}
}
Моя структура t_files:
typedef struct s_files
{
size_t len;
t_bool hidden;
int error;
char *path;
char *name;
char *sym_name;
char *rights;
char *uid;
char *gid;
char *time;
int nlink_max;
int size_max;
/*
** from stat
*/
int type;
int nlink;
int size;
t_bool rd;
struct s_files *files;
} t_files;
Эта ошибка возникает после нескольких рекурсивных вызовов. "files[i].files" инициализируется значением NULL в другом файле и при необходимости является malloc.
Рекурсивные вызовы могут вызвать проблемы?
Спасибо;)
1 ответ
Решение
У вас есть потенциальный доступ к массиву в ft_sort_ascii(), В ft_swap_files() у вас есть код:
*i = -1;
return ;
}
который возвращает к следующему коду в ft_sort_ascii():
ft_swap_files(files, &i);
if (files[i].files != NULL) // Underflow here if i == -1
{
ft_sort_ascii(files[i].files); // and here if it gets this far
}
который подстилает files[] массив. Вам нужно будет проверить, если i является допустимым индексом перед выполнением любого доступа к массиву с ним.