Troubleshooting a Crash Triggered by Clang Compiler Optimization

If someone told you that the following C++ function would cause the program to crash, what would you think it is that caused the problem?

std::string b2s(bool b) {
    return b ? "true" : "false";
}

If you were given more descriptions, for example:

The crash reappears with a certain probability.
The error message shows Program terminated with signal SIGSEGV.
The backtrace information is usually incomplete or even missing.
When the optimization level is higher than -O2, the crash is more likely to happen.
The crash only happens while using Clang, but not GCC.

Well, some of the veterans may already have a clue. Here's the minimal program that can reproduce the crash:

// file crash.cpp
#include <iostream>
#include <string>

std::string __attribute__((noinline)) b2s(bool b) {
    return b ? "true" : "false";
}

union {
    unsigned char c;
    bool b;
} volatile u;

int main() {
    u.c = 0x80;
    std::cout << b2s(u.b) << std::endl;
    return 0;
}

$ clang++ -O2 crash.cpp
$ ./a.out
truefalse,d$x4DdzRx

Segmentation fault (core dumped)

$ gdb ./a.out core.3699
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000012cfffff0d4 in ?? ()
(gdb) bt
#0  0x0000012cfffff0d4 in ?? ()
#1  0x00000064fffff0f4 in ?? ()
#2  0x00000078fffff124 in ?? ()
#3  0x000000b4fffff1e4 in ?? ()
#4  0x000000fcfffff234 in ?? ()
#5  0x00000144fffff2f4 in ?? ()
#6  0x0000018cfffff364 in ?? ()
#7  0x0000000000000014 in ?? ()
#8  0x0110780100527a01 in ?? ()
#9  0x0000019008070c1b in ?? ()
#10 0x0000001c00000010 in ?? ()
#11 0x0000002ffffff088 in ?? ()
#12 0xe2ab001010074400 in ?? ()
#13 0x0000000000000000 in ?? ()

Though incomplete, the backtrace information still indicates that the program did not crash in the first place. In such a case, to quickly locate the first scene, let's try AddressSanitizer (ASan).

$ clang++ -g -O2 -fno-omit-frame-pointer -fsanitize=address crash.cpp
$ ./a.out
=================================================================
==3699==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000552805 at pc 0x0000004ff83a bp 0x7ffd7610d240 sp 0x7ffd7610c9f0
READ of size 133 at 0x000000552805 thread T0
    #0 0x4ff839 in __asan_memcpy (a.out+0x4ff839)
    #1 0x5390a7 in b2s[abi:cxx11](bool) crash.cpp:6
    #2 0x5391be in main crash.cpp:16:18
    #3 0x7faed604df42 in __libc_start_main (/usr/lib64/libc.so.6+0x23f42)
    #4 0x41c43d in _start (a.out+0x41c43d)

0x000000552805 is located 59 bytes to the left of global variable '<string literal>' defined in 'crash.cpp:6:25' (0x552840) of size 6
  '<string literal>' is ascii string 'false'
0x000000552805 is located 0 bytes to the right of global variable '<string literal>' defined in 'crash.cpp:6:16' (0x552800) of size 5
  '<string literal>' is ascii string 'true'
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/dutor.hou/Wdir/nebula-graph/build/bug/a.out+0x4ff839) in __asan_memcpy
Shadow bytes around the buggy address:
…
...

From the information provided by ASan, we can see that global buffer overflow happened when the b2s(bool) function was reading the string constant true. Alright, let's take a "God View" at the abnormal function and the program. It seems like we can get such a conclusion: Because the bool type parameter b of the b2s function was not initialized, the value stored in b is neither 0 nor 1[1], and that caused the problem. But here's another question, why would such a value cause buffer overflow? If that interests you, change the type of b from bool to char or int and the problem will be fixed.

To answer the new question, we have to check what instructions does Clang++ generate from b2s. Before we do that, we should know:

In the sample program, the return value of b2s is a temporary std::string object, which is stored on the stack.
After C++ 11, GCC applies SBO (Small Buffer Optimization) by default on the implementation of std::string. The definition is something like this: std::string{ char *ptr; size_t size; union{ char buf[16]; size_t capacity}; }. For strings shorter than 16 bytes, no additional memory is required.

OK. Now let's take a look at the disassembling of b2s. I added some key comments.

(gdb) disas b2s
Dump of assembler code for function b2s[abi:cxx11](bool):
   0x00401200 <+0>:     push   %r14
   0x00401202 <+2>:     push   %rbx
   0x00401203 <+3>:     push   %rax
   0x00401204 <+4>:     mov    %rdi,%r14         # Save the starting address of the return value (a string) in R14.
   0x00401207 <+7>:     mov    $0x402010,%ecx    # Save the starting address of "true" in ecx.
   0x0040120c <+12>:    mov    $0x402015,%eax    # Save the starting address of "false" in eax.
   0x00401211 <+17>:    test   %esi,%esi         # Test whether parameter b has a non-zero value.
   0x00401213 <+19>:    cmovne %rcx,%rax         # If b is not zero, save the address of "true" in rax.
   0x00401217 <+23>:    lea    0x10(%rdi),%rdi   # Save the starting address of buf in the string in rdi.
                                                 #  It is also the first parameter of memcpy.
   0x0040121b <+27>:    mov    %rdi,(%r14)       # Save rdi in the string's PTR  field, i.e., SBO.
   0x0040121e <+30>:    mov    %esi,%ebx         # Save the value of b in ebx.
   0x00401220 <+32>:    xor    $0x5,%rbx         # Calculate the XOR value of 0x5 and save it in rbx (i.e., ebx).
                                                 # Note that if rbx is 0 or 1, then the value saved to rbx is 4 or 5,
                                                 # which is the length of "true" or "false". 
   0x00401224 <+36>:    mov    %rax,%rsi         # Save the starting address of the string in rsi, which is the second parameter of memcpY.
   0x00401227 <+39>:    mov    %rbx,%rdx         # Save the length of the string in rdx, which is the third parameter of memcpy.
   0x0040122a <+42>:    callq  <memcpy@plt>      # Call memcpy.
   0x0040122f <+47>:    mov    %rbx,0x8(%r14)    # Save the length of the string in string::size.
   0x00401233 <+51>:    movb   $0x0,0x10(%r14,%rbx,1)  # Add '\0' to the end of the string.
   0x00401239 <+57>:    mov    %r14,%rax         # Save the String address in rax, that is, the return value.
   0x0040123c <+60>:    add    $0x8,%rsp
   0x00401240 <+64>:    pop    %rbx
   0x00401241 <+65>:    pop    %r14
   0x00401243 <+67>:    retq
End of assembler dump.

At this point, the situation becomes crystal clear:

Clang++ assumes that the value of a Boolean is either 0 or 1.
During the compiling, the compiler has the length of true and false.
The compiler uses the XOR operations (0x5 ^ false == 5, 0x5 ^ true == 4) to calculate the length of the string to be copied.
When the compiler finds that the bool type value does not conform to the preceding assumption, the length calculation goes wrong.
Because the target address of memcpy is on the stack (for this example only), the stack buffer may overflow, causing the program to run off the rail and the backtrace information to be missing.

NOTE: [1]. The C++ standard requires a bool type value to represent at least two states: true and false, but does not specify the sizeof(bool). But on almost all compilers, a bool type value takes up an addressing unit, i.e., a byte. Therefore, from the storage perspective, the value range is from 0x00 to 0xFF, which represents 256 states.

Troubleshooting a Crash Triggered by Clang Compiler Optimization

You Might Also Like