Объявление массива в функции start_routine pthreads вызывает ошибку сегментации
#include <stdio.h>
#include <pthread.h>
void* function(void* arg){
int picture[4096][4096];
}
int main(){
int N=10, S=10;
pthread_t pids[10];
pthread_create(&pids[0], NULL, function, NULL);
pthread_join(pids[0], NULL);
return 0;
}
Я скомпилировал приведенный выше код с помощью: gcc test.c -pthread.
При запуске исполняемого файла происходит сбой с отображением: Segmentation fault.
Но если я уберу определение int picture[4096][4096];, он не рухнет.
Что может быть причиной этого?
Ответы 2
Я создал файл дампа ядра. Я запустил файл дампа ядра. Это дало мне следующее:
#0 0x00005643352ba745 in function (arg=<error reading variable: Cannot access memory at address 0x7fe80b054ed8>) at Pthred_kk.c:5
picture = <error reading variable picture (value requires 67108864 bytes, which is more than max-value-size)>
#1 0x00007fe80f6526db in start_thread (arg=0x7fe80f055700) at pthread_create.c:463
pd = 0x7fe80f055700
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140634661148416, 8554578219241222147, 140634661146560, 0, 0, 140724934020640,
-8545604918547140605, -8545605192128745469}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0,
cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#2 0x00007fe80f37b88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
picture = <ошибка чтения переменной picture (значение требует 67108864 байт, что больше, чем max-value-size)
В Linux максимальный размер стека для потока составляет около 8 МБ.
Как видите, размер (67108864 байта) picture больше максимального размера (8 МБ = 8 * 1024 * 1024 = 8388608).
@Amitwadhwa См. эту ссылку, чтобы узнать о создании дампа ядра jvns.ca/blog/2018/04/28/debugging-a-segfault-on-linux
Хотя прямого отношения к этому не имеет. Но просто спрашиваю, если у вас есть быстрый ответ. Я выполнил шаги в блоге, но не смог увидеть строку, которую вы вставили. Кроме того, я не уверен, как это выполнить symbol-file /path/to/my/binary sharedlibrary
1) ulimit -c неограниченно 2) sudo sysctl -w kernel.core_pattern=/tmp/core_%e_%p 3) gdb <исполняемый-файл> <файл дампа ядра>
После шага 2) файл дампа ядра будет храниться в папке /tmp. Вы можете изменить путь по своему усмотрению.
Я сделал это, но не смог увидеть в нем строчку picture = <error reading variable picture (value. Хотя вещи очень похожи
Программа сбоя:
#include <stdio.h>
#include <pthread.h>
void *function(void *arg)
{
int picture[4096][4096]; // 4096*4096*sizeof(int) = 67108864 bytes = 64 MB
}
int main()
{
pthread_t pids[10];
pthread_create(&pids[0],NULL, function, NULL);
pthread_join(pids[0],NULL);
return 0;
}
Программа вылетает во время выполнения:
$ gcc p.c -lpthread
$ ./a.out
Segmentation fault (core dumped)
Компоновка стека потоков
Размер стека по умолчанию для потока в GLIBC/pthread составляет 8 МБ. Во время создания потока дескриптор потока, также называемый блоком управления задачами (TCB), сохраняется в нижней части стека, а красная зона (защитная страница размером 4 КБ без разрешения на чтение/запись устанавливается в верхней части стека). Стек растет от старших адресов к младшим.
Результат программы под управлением strace:
$ strace -f ./a.out
[...]
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fee8d4dc000
mprotect(0x7fee8d4dd000, 8388608, PROT_READ|PROT_WRITE) = 0
brk(NULL) = 0x556cf1b72000
brk(0x556cf1b93000) = 0x556cf1b93000
clone(child_stack=0x7fee8dcdbfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTIDstrace: Process 3338 attached
, parent_tid=[3338], tls=0x7fee8dcdc700, child_tidptr=0x7fee8dcdc9d0) = 3338
[pid 3338] set_robust_list(0x7fee8dcdc9e0, 24 <unfinished ...>
[pid 3337] futex(0x7fee8dcdc9d0, FUTEX_WAIT, 3338, NULL <unfinished ...>
[pid 3338] <... set_robust_list resumed>) = 0
[pid 3338] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fee8d4dcef0} ---
[pid 3337] <... futex resumed>) = ?
[pid 3338] +++ killed by SIGSEGV (core dumped) +++
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
В предыдущем:
- Библиотека pthread получает размер стека по умолчанию с помощью вызова getrlimit(), который возвращает 8 МБ:
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 - Библиотека pthread выделяет зону стека размером 8 МБ + 4 КБ для защитной страницы с вызовом mmap() без прав на чтение/запись (т. е. PROT_NONE):
mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fee8d4dc000 - Библиотека pthreads вызывает mprotect() для установки разрешения на чтение/запись (т. е. PROT_READ|PROT_WRITE) для зоны памяти, за исключением первых 4 КБ защитной страницы (будет служить для обнаружения переполнения стека)
mprotect(0x7fee8d4dd000, 8388608, PROT_READ|PROT_WRITE) = 0 - Поток создается вызовом clone() (начало стека устанавливается по адресу 0x7fee8dcdbfb0)
clone(child_stack=0x7fee8dcdbfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[3338], tls=0x7fee8dcdc700, child_tidptr=0x7fee8dcdc9d0) = 3338
Отсюда следующая структура пространства памяти:
+ +--------------------+ 0x7fee8d4dc000
| | |
4 KB | | RED ZONE |
(PROT_NONE)| | (guard page) |
+ +--------------------+ 0x7fee8d4dd000
| | |
| | |
| | ^ |
8192 KB | | | |
(PROT_READ/WRITE) | Stack |
| | | |
| | | |
| +--------------------+ 0x7fee8dcdbfb0
| | |
| | TCB + TLS |
| | |
+ +--------------------+ 0x7fee8dcdd000
Почему ваша программа дала сбой
Точка входа потока определяет таблицу из 4096x4096x4 байтов, которая равна 64 МБ. Это слишком много для области стека длиной 8 МБ. Тем не менее, мы могли ожидать никакого сбоя, так как функция определяет огромную локальную таблицу, но в нее нет доступа для чтения/записи. Так что сбоя быть не должно.
Логи strace показывают, что сбой происходит при доступе к адресу 0x7fee8d4dcef0, который находится над областью стека в выделенной зоне памяти:
[pid 3338] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fee8d4dcef0} ---
Это на самом деле на странице защиты:
+ +--------------------+ 0x7fee8d4dc000
| | |
4 KB | | RED ZONE <--------- Trap @ si_addr=0x7fee8d4dcef0
(PROT_NONE)| | | si_code=SEGV_ACCERR
+ +--------------------+ 0x7fee8d4dd000
| | |
| | |
| | ^ |
8192 KB | | | |
(PROT_READ/WRITE) | Stack |
| | | |
| | | |
| +--------------------+ 0x7fee8dcdbfb0
| | |
| | TCB + TLS |
| | |
+ +--------------------+ 0x7fee8dcdd000
Анализ дампа ядра под gdb показывает следующее место для сбоя:
$ gdb a.out core
[...]
(gdb) where
#0 0x00005594eb9461a0 in function (arg=<error reading variable: Cannot access memory at address 0x7fe95459ded8>) at p.c:56
#1 0x00007fe95879d609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#2 0x00007fe9586c4293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) disas /m
Dump of assembler code for function function:
56 void* function(void* arg){
0x00005594eb946189 <+0>: endbr64
0x00005594eb94618d <+4>: push %rbp
0x00005594eb94618e <+5>: mov %rsp,%rbp
0x00005594eb946191 <+8>: lea -0x4000000(%rsp),%r11
0x00005594eb946199 <+16>: sub $0x1000,%rsp
=> 0x00005594eb9461a0 <+23>: orq $0x0,(%rsp)
0x00005594eb9461a5 <+28>: cmp %r11,%rsp
0x00005594eb9461a8 <+31>: jne 0x5594eb946199 <function+16>
0x00005594eb9461aa <+33>: sub $0x20,%rsp
0x00005594eb9461ae <+37>: mov %rdi,-0x4000018(%rbp)
0x00005594eb9461b5 <+44>: mov %fs:0x28,%rax
0x00005594eb9461be <+53>: mov %rax,-0x8(%rbp)
0x00005594eb9461c2 <+57>: xor %eax,%eax
57 int picture[4096][4096];
58 }
Приведенный выше код дизассемблирования точки входа потока показывает, что gcc генерирует доступ к стеку каждые 4 КБ (размер страницы памяти). Сначала он устанавливает регистр R11 с адресом начала локальной таблицы (0x4000000 — это 4096x4096xsizeof(int) = 67108864 байта):
0x00005594eb946191 <+8>: lea -0x4000000(%rsp),%r11
Затем он зацикливает содержимое стека на 0 каждые 4096 байт (0x1000):
0x00005594eb946199 <+16>: sub $0x1000,%rsp
=> 0x00005594eb9461a0 <+23>: orq $0x0,(%rsp)
0x00005594eb9461a5 <+28>: cmp %r11,%rsp
0x00005594eb9461a8 <+31>: jne 0x5594eb946199 <function+16>
Следовательно, сбой, потому что в какой-то момент инструкция orq появляется на странице защиты стека!
Примечание:
- Причина «очевидно бесполезного» сгенерированного кода — защита от уязвимостей класса Stack Clash, как описано в этом ответе
- Конечно, компиляция того же кода с параметром оптимизации не приведет к сбою, поскольку function() не будет содержать никакого кода:
$ gcc p.c -lpthread -O2
$ ./a.out
Оптимизированный код дизассемблирования функции() представляет собой простой «возврат»:
$ objdump -S a.out
[...]
00000000000011f0 <function>:
11f0: f3 0f 1e fa endbr64
11f4: c3 retq
11f5: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
11fc: 00 00 00
11ff: 90 nop
Как установить больший стек для потока
Как видно выше, по умолчанию библиотека GLIBC/pthread выделяет стек по умолчанию размером 8 МБ. Но он также предоставляет возможность установить стек, выделенный пользователем, или просто определить размер стека, выполнив следующие действия:
- Определите атрибуты потока с помощью pthread_attr_init();
- Установите размер стека в атрибутах с помощью pthread_attr_setstacksize();
- Передайте атрибуты в качестве второго параметра в pthread_create();
- Вызовите pthread_attr_destroy(), чтобы освободить атрибуты.
Вот расширенная версия программы, которая определяет для потока стек размером 65 МБ:
#include <stdio.h>
#include <pthread.h>
void* function(void* arg)
{
int picture[4096][4096]; // 4096*4096*sizeof(int) = 67108864 bytes = 64 MB
}
int main(void)
{
pthread_t pids[10];
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setstacksize(&attr, 65*1024*1024);
pthread_create(&pids[0], &attr, function, NULL);
pthread_join(pids[0], NULL);
pthread_attr_destroy(&attr);
return 0;
}
Сборка и исполнение:
$ gcc p2.c -lpthread
$ ./a.out
Нет никакого сбоя. С помощью strace мы можем проверить поведение:
$ strace ./a.out
[...]
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
mmap(NULL, 68161536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fe55afd3000
mprotect(0x7fe55afd4000, 68157440, PROT_READ|PROT_WRITE) = 0
brk(NULL) = 0x55b9d7ade000
brk(0x55b9d7aff000) = 0x55b9d7aff000
clone(child_stack=0x7fe55f0d2fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[5199], tls=0x7fe55f0d3700, child_tidptr=0x7fe55f0d39d0) = 5199
futex(0x7fe55f0d39d0, FUTEX_WAIT, 5199, NULL) = 0
munmap(0x7fe55afd3000, 68161536) = 0
exit_group(0) = ?
+++ exited with 0 +++
Мы можем видеть в приведенных выше следах:
- Вызов mmap() из 65 МБ + 4 КБ = 66564 КБ = 68161536 байт (т. е. 65 МБ + 4 КБ защитной страницы, округленной до большей границы страницы в 4 КБ)
mmap(NULL, 68161536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fe55afd3000 - Вызов mprotect() для первых 68157440 байт, чтобы установить защитную страницу в оставшихся 4 КБ
mprotect(0x7fe55afd4000, 68157440, PROT_READ|PROT_WRITE) = 0
Отсюда новая структура пространства памяти:
+ +--------------------+ 0x7fe55afd3000
| | |
4 KB | | RED ZONE |
(PROT_NONE)| | |
+ +--------------------+ 0x7fe55afd4000
| | |
| | |
| | ^ |
66560 KB | | | |
(PROT_READ/WRITE) | Stack |
| | | |
| | | |
| +--------------------+ 0x7fe55f0d2fb0
| | |
| | TCB + TLS |
| | |
+ +--------------------+ 0x7FE55F0D4000
Заключение
От простой программы, заканчивающейся странным крахом, мы воспользовались возможностью изучить структуру стека потока в библиотеке GLIBC/pthread, а также механизм защиты от переполнения стека и конфигурацию размера стека.
Однако с точки зрения дизайна программы мы никогда не должны размещать такие огромные переменные в стеке. В текущей программе таблица должна быть динамически выделена или определена как глобальная переменная (в локальном хранилище потока) для примера. Но это другая история...
Спасибо Это было действительно круто. На заметку. Как вы взяли дамп ядра, чтобы увидеть эту ошибку? И есть ли способ увеличить размер стека потока?