堆棧內存溢出
  簡體   English   中英

在 pthreads start_routine function 中聲明數組導致分段錯誤

[英]Declaring array in pthreads start_routine function causing segmentation fault

 原文  2020-12-12 08:49:19  2   2    c/ segmentation-fault/ pthreads/ stack-overflow

問題描述

#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 個解決方案

解決方案1
 2 已采納  2020-12-12 11:44:07

崩潰的程序是：

#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 MB 。 在線程創建時，線程描述符也稱為任務控制塊（TCB），存儲在堆棧底部和一個紅色區域（在堆棧頂部設置了 4 KB 的沒有讀/寫權限的保護頁）。 堆棧從高地址向低地址增長。

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 MB： prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
  • pthread 庫通過調用mmap()分配 8MB + 4 KB 保護頁的堆棧區域，沒有讀/寫權限（即PROT_NONE ）： mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fee8d4dc000
  • The pthreads library calls mprotect() to set the read/write (ie PROT_READ|PROT_WRITE ) permission on the memory zone except the first 4 KB of guard page (will serve to detect the stack overflows) 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

因此以下 memory 空間布局：

              +      +--------------------+ 0x7fee8d4dc000
              |      |                    |
      4 KB    |      |      RED ZONE      |
   (PROT_NONE)|      |    (guard page)    |
              +      +--------------------+ 0x7fee8d4dd000
              |      |                    |
              |      |                    |
              |      |          ^         |
    8192 KB   |      |          |         |
(PROT_READ/WRITE)    |        Stack       |
              |      |          |         |
              |      |          |         |
              |      +--------------------+ 0x7fee8dcdbfb0
              |      |                    |
              |      |     TCB + TLS      |
              |      |                    |
              +      +--------------------+ 0x7fee8dcdd000

為什么你的程序崩潰了

線程入口點定義了一個4096x4096x4字節的表，等於 64 MB。 這對於 8 MB 長堆棧區域來說太多了。 但是，我們可以預期根本不會崩潰，因為 function 定義了一個巨大的本地表，但沒有對其進行讀/寫訪問。 因此，不應發生崩潰。

strace日志顯示，訪問地址0x7fee8d4dcef0時發生崩潰，該地址位於分配的 memory 區域中的堆棧區域上方： [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 KB（內存頁大小）生成一次堆棧訪問。 它首先將R11寄存器設置為本地表開頭的地址（ 0x4000000是4096x4096xsizeof(int) = 67108864 字節）：

   0x00005594eb946191 <+8>: lea    -0x4000000(%rsp),%r11

然后，它每 4096 個字節（0x1000）循環“oring”堆棧的內容為 0：

   0x00005594eb946199 <+16>:    sub    $0x1000,%rsp
=> 0x00005594eb9461a0 <+23>:    orq    $0x0,(%rsp)
   0x00005594eb9461a5 <+28>:    cmp    %r11,%rsp
   0x00005594eb9461a8 <+31>:    jne    0x5594eb946199 <function+16>

因此，崩潰是因為在某些時候， orq指令出現在堆棧的保護頁中！

注意：

  • “顯然無用”生成代碼的原因是針對堆棧沖突 class 漏洞的保護，如本答案中所述
  • 當然，使用優化選項編譯相同的代碼不會觸發任何崩潰，因為function()不會包含任何代碼：
$ gcc p.c -lpthread -O2
$ ./a.out

function()的優化反匯編代碼是一個簡單的“返回”：

$ 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 MB 的默認堆棧。 但它也提供了設置用戶分配的堆棧的能力，或者通過以下步驟簡單地定義堆棧大小：

這是該程序的增強版本，它為線程定義了 65 MB 的堆棧：

#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 MB + 4KB = 66564 KB = 68161536 字節（即65 MB + 4 KB的保護頁面向上舍入到更大的 4 KB 頁面邊界）
    mmap(NULL, 68161536, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fe55afd3000
  • 在前 68157440 個字節上調用mprotect()以在剩余的 4KB 中設置保護頁
    mprotect(0x7fe55afd4000, 68157440, PROT_READ|PROT_WRITE) = 0

因此，新的 memory 空間布局：

              +      +--------------------+ 0x7fe55afd3000
              |      |                    |
      4 KB    |      |      RED ZONE      |
   (PROT_NONE)|      |                    |              
              +      +--------------------+ 0x7fe55afd4000
              |      |                    |
              |      |                    |
              |      |          ^         |
   66560 KB   |      |          |         |
(PROT_READ/WRITE)    |        Stack       |
              |      |          |         |
              |      |          |         |
              |      +--------------------+ 0x7fe55f0d2fb0
              |      |                    |
              |      |     TCB + TLS      |
              |      |                    |
              +      +--------------------+ 0x7FE55F0D4000

結論

從一個簡單的程序結束到一個奇怪的崩潰，我們借此機會研究了GLIBC/pthread庫中線程的堆棧布局以及堆棧溢出的保護機制和堆棧大小配置。
但是，從程序設計的角度來看，我們不應該在堆棧中分配這么大的變量。 在當前程序中，表應該是動態分配或定義為全局變量（在線程本地存儲中）的例子。 但這是另一個故事……

解決方案2
 1  2020-12-12 09:26:05

我生成了核心轉儲文件。 我運行了核心轉儲文件。 它給了我以下信息：

#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

圖片=<錯誤讀取變量圖片（值需要67108864字節，大於max-value-size）

在 linux 中，線程的最大堆棧大小約為 8MB。
如您所見， picture的大小（67108864 字節）大於最大大小（8MB = 8 * 1024 *1024 = 8388608）。

暫無
暫無

聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

相關問題 C，Pthreads-如何重新執行指定的函數或start_routine 大型陣列導致分段故障 pThreads分段錯誤 使用pthreads的分段錯誤 Pthreads無法解釋的分段錯誤 在 function 中打印二維數組元素會導致分段錯誤 是什么導致此 function 中的分段錯誤？ 線程ID在main（）和start_routine（）中不同-Pthread 使用宏強制轉換pthread的start_routine參數 傳遞給 pthread_create 的“start_routine”的類型是什么
相關標簽
 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM