Question

关于以下功能，我的调试器在完成此功能时会向我显示__stack_chk_fail。

我的系统是Mac OS。

这是因为我的堆栈通过检查引用而溢出。

同样根据我的实验，如果设置vocab_size = 30000，则会显示__stack_chk_fail错误，但是当vocab_size = 20000时，它就可以了。

所以我相信

vocab = (struct vocab_word *)malloc ((size_t) ((vocab_size + 1) * sizeof(struct vocab_word)));

是个问题。但是malloc在堆上分配内存而不是堆栈，所以我想知道我哪里出错了？

void populate_vocab(){
    FILE *fin;
    fin = fopen(word_file, "rb");
    vocab = (struct vocab_word *)malloc ((size_t) ((vocab_size + 1) * sizeof(struct vocab_word)));
    char word[MAX_STRING];
    int word_idx = 0;
    int num = 0;
    boolean word_mode = 1;
    long long cur_vocab_size = 0;

    while (!feof(fin)) {
        ch = fgetc(fin);

        if(ch == ' '){
            word_mode = 0;
        }else if(ch == '\n'){
            word_mode = 1;
            word[word_idx] = 0;
            vocab[cur_vocab_size].word = (char *)calloc(word_idx, sizeof(char));
            strcpy(vocab[cur_vocab_size].word,word);
            vocab[cur_vocab_size].cn = num;
            cur_vocab_size++;
            if (cur_vocab_size >= vocab_size){
                break;
            }
            //fresh var
            word_idx = 0;
            num = 0;

        }else{
            if(word_mode){
                word[word_idx] = ch;
                word_idx ++;
            }else{
                num = num * 10;
                num += ch - '0';
            }
        }
    }
    fclose(fin);
}

Answer 1

根据评论，我找出原因。其中一个字超过MAX_STRING，导致堆栈溢出。

Answer 2

我建议在Valgrind或AddressSanitizer下运行崩溃的程序。在最新的macOS上，仅AddressSanitizer可用。

__stack_chk_fail崩溃后的Stacktrace仅告诉您在哪里检测到了问题（使堆栈崩溃的堆栈溢出）。当发生溢出时，AddressSanitizer可以正确告诉您。

要使用AddressSanitizer，请使用最新的clang或gcc并使用标志进行编译

clang -fsanitize=address -fno-omit-frame-pointer -O1 -g hello.c

AddressSanitizer的报告如下所示

$ ../cmake-build-debug/cpp/examples/broker 
broker listening on 5672
=================================================================
==42793==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x70000c4bcbe0 at pc 0x0001013663e1 bp 0x70000c4bc830 sp 0x70000c4bc828
WRITE of size 8 at 0x70000c4bcbe0 thread T3
    #0 0x1013663e0 in pni_split_mechs sasl.c:443
    #1 0x1013646ea in pni_post_sasl_frame sasl.c:480
    #2 0x101357fad in pn_output_write_sasl sasl.c:677
    #3 0x101323909 in transport_produce transport.c:2751
    #4 0x10131ffd3 in pn_transport_pending transport.c:3030
    #5 0x1012b8755 in pn_connection_driver_write_buffer connection_driver.c:120
    #6 0x10120240f in leader_process_pconnection libuv.c:909
    #7 0x1011f8b48 in leader_lead_lh libuv.c:1008
    #8 0x1011f94f3 in pn_proactor_wait libuv.c:1062
    #9 0x10188c55d in proton::container::impl::thread() proactor_container_impl.cpp:753
    #10 0x1018bca31 in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (proton::container::impl::*)(), proton::container::impl*> >(void*) thread:352
    #11 0x7fff6987f2ea in _pthread_body (libsystem_pthread.dylib:x86_64+0x32ea)
    #12 0x7fff69882248 in _pthread_start (libsystem_pthread.dylib:x86_64+0x6248)
    #13 0x7fff6987e40c in thread_start (libsystem_pthread.dylib:x86_64+0x240c)

Address 0x70000c4bcbe0 is located in stack of thread T3 at offset 192 in frame
    #0 0x101363ccf in pni_post_sasl_frame sasl.c:462

  This frame has 3 object(s):
    [32, 48) 'out' (line 464)
    [64, 192) 'mechs' (line 475) <== Memory access at offset 192 overflows this variable
    [224, 228) 'count' (line 478)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
Thread T3 created by T0 here:
    #0 0x101f5dadd in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x56add)
    #1 0x1018bc4ab in std::__1::thread::thread<void (proton::container::impl::*)(), proton::container::impl*, void>(void (proton::container::impl::*&&)(), proton::container::impl*&&) thread:368
    #2 0x10188da97 in proton::container::impl::run(int) proactor_container_impl.cpp:802
    #3 0x100f0223c in main broker.cpp:427
    #4 0x7fff6968b3d4 in start (libdyld.dylib:x86_64+0x163d4)

SUMMARY: AddressSanitizer: stack-buffer-overflow sasl.c:443 in pni_split_mechs
Shadow bytes around the buggy address:
  0x1e0001897920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e0001897930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e0001897940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e0001897950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e0001897960: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00 00 00
=>0x1e0001897970: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
  0x1e0001897980: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e0001897990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e00018979a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e00018979b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1e00018979c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==42793==ABORTING
Abort trap: 6

为什么__stack_chk_fail会在我的代码中发生？

2 个答案: