Linux如何调试内存泄漏

ITlover00 2020-05-26

内存泄漏是指由于疏忽或错误造成程序未能释放已经不再使用的内存。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费。

我们平时开发过程中不可避免的会遇到内存泄漏问题，你是如何排查的呢？估计你是使用下面这几个工具吧？

  • valgrind

  • mtrace

  • dmalloc

  • ccmalloc

  • memwatch

  • debug_new

这里程序喵向大家推荐新的一个排查内存泄漏的工具：AddressSanitizer(ASan)，该工具为gcc自带，4.8以上版本都可以使用，支持Linux、OS、Android等多种平台，不止可以检测内存泄漏，它其实是一个内存错误检测工具，可以检测的问题有：

  • 内存泄漏

  • 堆栈和全局内存越界访问

  • free后继续使用

  • 局部内存被外层使用

  • Initialization order bugs(中文不知道怎么翻译才好，后面有代码举例，重要)

使用方法直接看我下面的代码：

检测内存泄漏

内存泄漏代码：

#include <stdlib.h>

void func1() { malloc(7); }

void func2() { malloc(5); }

int main() {
   func1();
   func2();
   return 0;
}

编译and输出：

gcc -fsanitize=address -g test_leak.c && ./a.out

=================================================================
==103==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 7 byte(s) in 1 object(s) allocated from:
   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
   #1 0x7f95b36007f7 in func1() /home/wangzhiqiang/test/test_leak.cc:3
   #2 0x7f95b3600814 in main /home/wangzhiqiang/test/test_leak.cc:8
   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Direct leak of 5 byte(s) in 1 object(s) allocated from:
   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
   #1 0x7f95b3600808 in func2() /home/wangzhiqiang/test/test_leak.cc:5
   #2 0x7f95b3600819 in main /home/wangzhiqiang/test/test_leak.cc:9
   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: 12 byte(s) leaked in 2 allocation(s).

编译方式很简单，只需要添加-fsanitize=address -g就可以检测出具体产生内存泄漏的位置以及泄漏空间的大小。

检测堆栈内存越界访问

示例：

#include <iostream>

int main() {
   int *array = new int[100];
   array[0] = 0;
   int res = array[100];  // out of bounds
   delete[] array;
   return res;
}

编译and输出:

gcc -fsanitize=address -g test_leak.c && ./a.out
   
=================================================================
==110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140000001d0 at pc 0x7f0e06400d2e bp 0x7ffff5963f10 sp 0x7ffff5963f00
READ of size 4 at 0x6140000001d0 thread T0
   #0 0x7f0e06400d2d in main /home/wangzhiqiang/test/test_leak.cc:6
   #1 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
   #2 0x7f0e06400bb9 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xbb9)

0x6140000001d0 is located 0 bytes to the right of 400-byte region [0x614000000040,0x6140000001d0)
allocated by thread T0 here:
   #0 0x7f0e05120608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
   #1 0x7f0e06400cab in main /home/wangzhiqiang/test/test_leak.cc:4
   #2 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
 0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c287fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
 0x0c287fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0c287fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c287fff8030: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa
 0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c287fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c287fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
 0x0c287fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==110==ABORTING

可以方便定位到堆栈内存越界访问的错误。

全局内存越界访问：

示例：

#include <iostream>

int global_array[100] = {0};

int main() {
   int res = global_array[100];  // out of bounds
   return 0;
}

编译and输出：

gcc -fsanitize=address -g test_leak.c && ./a.out
=================================================================
==116==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f42e6e02310 at pc 0x7f42e6c00c84 bp 0x7fffdda52780 sp 0x7fffdda52770
READ of size 4 at 0x7f42e6e02310 thread T0
   #0 0x7f42e6c00c83 in main /home/wangzhiqiang/test/test_leak.cc:6
   #1 0x7f42e50d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
   #2 0x7f42e6c00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)

0x7f42e6e02310 is located 0 bytes to the right of global variable ‘global_array‘ defined in ‘test_leak.cc:3:5‘ (0x7f42e6e02180) of size 400
SUMMARY: AddressSanitizer: global-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
 0x0fe8dcdb8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb8420: 00 00 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9
 0x0fe8dcdb8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe8dcdb8460: 00 00[f9]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
 0x0fe8dcdb8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0x0fe8dcdb84b0: 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
==116==ABORTING

局部内存被外层使用

示例：

#include <iostream>

volatile int *p = 0;

int main() {
{
   int x = 0;
   p = &x;
}
 *p = 5;
 return 0;
}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==243==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffce12a4b0 at pc 0x7f3993e00e7e bp 0x7fffce12a480 sp 0x7fffce12a470
WRITE of size 4 at 0x7fffce12a4b0 thread T0
  #0 0x7f3993e00e7d in main /home/wangzhiqiang/test/test_leak.cc:10
  #1 0x7f39922d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
  #2 0x7f3993e00c89 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xc89)

Address 0x7fffce12a4b0 is located in stack of thread T0 at offset 32 in frame
  #0 0x7f3993e00d79 in main /home/wangzhiqiang/test/test_leak.cc:5

This frame has 1 object(s):
  [32, 36) ‘x‘ <== Memory access at offset 32 is inside this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
    (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /home/wangzhiqiang/test/test_leak.cc:10 in main
Shadow bytes around the buggy address:
0x100079c1d440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100079c1d490: 00 00 f1 f1 f1 f1[f8]f2 f2 f2 00 00 00 00 00 00
0x100079c1d4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100079c1d4e0: 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
==243==ABORTING

free后被使用

示例：

#include <iostream>

int main() {
    int *array = new int[100];
    delete[] array;
    int a = array[0];  // error
    return 0;
}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out
=================================================================
==282==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x7f209fa00caa bp 0x7ffff2a15020 sp 0x7ffff2a15010
READ of size 4 at 0x614000000040 thread T0
    #0 0x7f209fa00ca9 in main /home/wangzhiqiang/test/test_leak.cc:6
    #1 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #2 0x7f209fa00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)

0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)
freed by thread T0 here:
    #0 0x7f209e721480 in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe1480)
    #1 0x7f209fa00c72 in main /home/wangzhiqiang/test/test_leak.cc:5
    #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

previously allocated by thread T0 here:
    #0 0x7f209e720608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)
    #1 0x7f209fa00c5b in main /home/wangzhiqiang/test/test_leak.cc:4
    #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: heap-use-after-free /home/wangzhiqiang/test/test_leak.cc:6 in main
Shadow bytes around the buggy address:
  0x0c287fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c287fff8000: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd
  0x0c287fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c287fff8030: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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
==282==ABORTING

Initialization order bugs

示例，这里有两个文件：

// test_memory1.cc
#include <stdio.h>

extern int extern_global;
int read_extern_global() { return extern_global; }

int x = read_extern_global() + 1;

int main() {
    printf("%d\n", x);
    return 0;
}
// test_memory2.cc

int foo() { return 123; }
int extern_global = foo();

第一种编译方式输出如下：

g++ test_memory1.cc test_memory2.cc && ./a.out
1

第二种编译方式输出如下：

g++ test_memory2.cc test_memory1.cc && ./a.out
124

这种问题我们平时编程过程中可以都不会太注意，然而通过ASan可以检测出这种潜在的bug：

编译and输出：

g++ -fsanitize=address -g test_memory1.cc test_memory2.cc

ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./a.out
=================================================================
==419==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f46c20021a0 at pc 0x7f46c1e00c28 bp 0x7fffe423d920 sp 0x7fffe423d910
READ of size 4 at 0x7f46c20021a0 thread T0
    #0 0x7f46c1e00c27 in read_extern_global() /home/wangzhiqiang/test/test_memory1.cc:3
    #1 0x7f46c1e00cb3 in __static_initialization_and_destruction_0 /home/wangzhiqiang/test/test_memory1.cc:4
    #2 0x7f46c1e00d0a in _GLOBAL__sub_I__Z18read_extern_globalv /home/wangzhiqiang/test/test_memory1.cc:8
    #3 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)
    #4 0x7f46c0461b27 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b27)
    #5 0x7f46c1e00b09 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb09)

0x7f46c20021a0 is located 0 bytes inside of global variable ‘extern_global‘ defined in ‘test_memory2.cc:2:5‘ (0x7f46c20021a0) of size 4
  registered at:
    #0 0x7f46c08764a8  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x364a8)
    #1 0x7f46c1e00e0b in _GLOBAL__sub_I_00099_1__Z3foov (/mnt/d/wzq/wzq/util/test/a.out+0xe0b)
    #2 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)

SUMMARY: AddressSanitizer: initialization-order-fiasco /home/wangzhiqiang/test/test_memory1.cc:3 in read_extern_global()
Shadow bytes around the buggy address:
  0x0fe9583f83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8420: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
=>0x0fe9583f8430: 00 00 00 00[f6]f6 f6 f6 f6 f6 f6 f6 00 00 00 00
  0x0fe9583f8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0fe9583f8480: 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
==419==ABORTING

注意：这里在运行程序前需要添加环境变量：

ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true

小总结

ASan是个很好的检测内存问题的工具，不需要配置环境，使用还方便，编译时只需要-fsanitize=address -g就可以，运行程序时候可以选择添加对应的ASAN_OPTIONS环境变量就可以检测出很多内存问题。它的错误信息也很有用，明确指出当前是什么类型的内存错误，如：

  • detected memory leaks

  • heap-buffer-overflow

  • stack-buffer-overflow

  • global-buffer-overflow

  • heap-use-after-free

  • initialization-order-fiasco

具体可以看google的官方文档：https://github.com/google/sanitizers/wiki/AddressSanitizer

内存泄漏是指由于疏忽或错误造成程序未能释放已经不再使用的内存。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费。

我们平时开发过程中不可避免的会遇到内存泄漏问题，你是如何排查的呢？估计你是使用下面这几个工具吧？

  • valgrind

  • mtrace

  • dmalloc

  • ccmalloc

  • memwatch

  • debug_new

这里程序喵向大家推荐新的一个排查内存泄漏的工具：AddressSanitizer(ASan)，该工具为gcc自带，4.8以上版本都可以使用，支持Linux、OS、Android等多种平台，不止可以检测内存泄漏，它其实是一个内存错误检测工具，可以检测的问题有：

  • 内存泄漏

  • 堆栈和全局内存越界访问

  • free后继续使用

  • 局部内存被外层使用

  • Initialization order bugs(中文不知道怎么翻译才好，后面有代码举例，重要)

使用方法直接看我下面的代码：

检测内存泄漏

内存泄漏代码：

#include <stdlib.h>void func1() { malloc(7); }void func2() { malloc(5); }int main() {   func1();   func2();   return 0;}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================103==ERROR: LeakSanitizer: detected memory leaksDirect leak of 7 byte(s) in 1 object(s) allocated from:   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)   #1 0x7f95b36007f7 in func1() /home/wangzhiqiang/test/test_leak.cc:3   #2 0x7f95b3600814 in main /home/wangzhiqiang/test/test_leak.cc:8   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)Direct leak of 5 byte(s) in 1 object(s) allocated from:   #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)   #1 0x7f95b3600808 in func2() /home/wangzhiqiang/test/test_leak.cc:5   #2 0x7f95b3600819 in main /home/wangzhiqiang/test/test_leak.cc:9   #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)SUMMARY: AddressSanitizer: 12 byte(s) leaked in 2 allocation(s).

编译方式很简单，只需要添加-fsanitize=address -g就可以检测出具体产生内存泄漏的位置以及泄漏空间的大小。

检测堆栈内存越界访问

示例：

#include <iostream>int main() {   int *array = new int[100];   array[0] = 0;   int res = array[100];  // out of bounds   delete[] array;   return res;}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140000001d0 at pc 0x7f0e06400d2e bp 0x7ffff5963f10 sp 0x7ffff5963f00READ of size 4 at 0x6140000001d0 thread T0   #0 0x7f0e06400d2d in main /home/wangzhiqiang/test/test_leak.cc:6   #1 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)   #2 0x7f0e06400bb9 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xbb9)0x6140000001d0 is located 0 bytes to the right of 400-byte region [0x614000000040,0x6140000001d0)allocated by thread T0 here:   #0 0x7f0e05120608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)   #1 0x7f0e06400cab in main /home/wangzhiqiang/test/test_leak.cc:4   #2 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c287fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8030: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa 0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow 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==110==ABORTING

可以方便定位到堆栈内存越界访问的错误。

全局内存越界访问：

示例：

#include <iostream>int global_array[100] = {0};int main() {   int res = global_array[100];  // out of bounds   return 0;}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================116==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f42e6e02310 at pc 0x7f42e6c00c84 bp 0x7fffdda52780 sp 0x7fffdda52770READ of size 4 at 0x7f42e6e02310 thread T0   #0 0x7f42e6c00c83 in main /home/wangzhiqiang/test/test_leak.cc:6   #1 0x7f42e50d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)   #2 0x7f42e6c00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)0x7f42e6e02310 is located 0 bytes to the right of global variable ‘global_array‘ defined in ‘test_leak.cc:3:5‘ (0x7f42e6e02180) of size 400SUMMARY: AddressSanitizer: global-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0fe8dcdb8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8420: 00 00 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 0x0fe8dcdb8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0fe8dcdb8460: 00 00[f9]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0fe8dcdb8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow 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==116==ABORTING

局部内存被外层使用

示例：

#include <iostream>volatile int *p = 0;int main() {{   int x = 0;   p = &x;} *p = 5; return 0;}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================243==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffce12a4b0 at pc 0x7f3993e00e7e bp 0x7fffce12a480 sp 0x7fffce12a470WRITE of size 4 at 0x7fffce12a4b0 thread T0  #0 0x7f3993e00e7d in main /home/wangzhiqiang/test/test_leak.cc:10  #1 0x7f39922d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)  #2 0x7f3993e00c89 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xc89)Address 0x7fffce12a4b0 is located in stack of thread T0 at offset 32 in frame  #0 0x7f3993e00d79 in main /home/wangzhiqiang/test/test_leak.cc:5This frame has 1 object(s):  [32, 36) ‘x‘ <== Memory access at offset 32 is inside this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext    (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-use-after-scope /home/wangzhiqiang/test/test_leak.cc:10 in mainShadow bytes around the buggy address:0x100079c1d440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x100079c1d490: 00 00 f1 f1 f1 f1[f8]f2 f2 f2 00 00 00 00 00 000x100079c1d4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes):Addressable:           00Partially addressable: 01 02 03 04 05 06 07Heap left redzone:       faFreed heap region:       fdStack left redzone:     f1Stack mid redzone:       f2Stack right redzone:     f3Stack after return:     f5Stack use after scope:   f8Global redzone:         f9Global init order:       f6Poisoned by user:       f7Container overflow:     fcArray cookie:           acIntra object redzone:   bbASan internal:           feLeft alloca redzone:     caRight alloca redzone:   cb==243==ABORTING

free后被使用

示例：

#include <iostream>int main() {    int *array = new int[100];    delete[] array;    int a = array[0];  // error    return 0;}

编译and输出：

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================282==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x7f209fa00caa bp 0x7ffff2a15020 sp 0x7ffff2a15010READ of size 4 at 0x614000000040 thread T0    #0 0x7f209fa00ca9 in main /home/wangzhiqiang/test/test_leak.cc:6    #1 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)    #2 0x7f209fa00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)freed by thread T0 here:    #0 0x7f209e721480 in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe1480)    #1 0x7f209fa00c72 in main /home/wangzhiqiang/test/test_leak.cc:5    #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)previously allocated by thread T0 here:    #0 0x7f209e720608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608)    #1 0x7f209fa00c5b in main /home/wangzhiqiang/test/test_leak.cc:4    #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)SUMMARY: AddressSanitizer: heap-use-after-free /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address:  0x0c287fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8000: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd  0x0c287fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd  0x0c287fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd  0x0c287fff8030: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa  0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa  0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow 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==282==ABORTING

Initialization order bugs

示例，这里有两个文件：

// test_memory1.cc#include <stdio.h>extern int extern_global;int read_extern_global() { return extern_global; }int x = read_extern_global() + 1;int main() {    printf("%d\n", x);    return 0;}
// test_memory2.ccint foo() { return 123; }int extern_global = foo();

第一种编译方式输出如下：

g++ test_memory1.cc test_memory2.cc && ./a.out1

第二种编译方式输出如下：

g++ test_memory2.cc test_memory1.cc && ./a.out124

这种问题我们平时编程过程中可以都不会太注意，然而通过ASan可以检测出这种潜在的bug：

编译and输出：

g++ -fsanitize=address -g test_memory1.cc test_memory2.ccASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./a.out===================================================================419==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f46c20021a0 at pc 0x7f46c1e00c28 bp 0x7fffe423d920 sp 0x7fffe423d910READ of size 4 at 0x7f46c20021a0 thread T0    #0 0x7f46c1e00c27 in read_extern_global() /home/wangzhiqiang/test/test_memory1.cc:3    #1 0x7f46c1e00cb3 in __static_initialization_and_destruction_0 /home/wangzhiqiang/test/test_memory1.cc:4    #2 0x7f46c1e00d0a in _GLOBAL__sub_I__Z18read_extern_globalv /home/wangzhiqiang/test/test_memory1.cc:8    #3 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)    #4 0x7f46c0461b27 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b27)    #5 0x7f46c1e00b09 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb09)0x7f46c20021a0 is located 0 bytes inside of global variable ‘extern_global‘ defined in ‘test_memory2.cc:2:5‘ (0x7f46c20021a0) of size 4  registered at:    #0 0x7f46c08764a8  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x364a8)    #1 0x7f46c1e00e0b in _GLOBAL__sub_I_00099_1__Z3foov (/mnt/d/wzq/wzq/util/test/a.out+0xe0b)    #2 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)SUMMARY: AddressSanitizer: initialization-order-fiasco /home/wangzhiqiang/test/test_memory1.cc:3 in read_extern_global()Shadow bytes around the buggy address:  0x0fe9583f83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8420: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9=>0x0fe9583f8430: 00 00 00 00[f6]f6 f6 f6 f6 f6 f6 f6 00 00 00 00  0x0fe9583f8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  0x0fe9583f8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow 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==419==ABORTING

注意：这里在运行程序前需要添加环境变量：

ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true

小总结

ASan是个很好的检测内存问题的工具，不需要配置环境，使用还方便，编译时只需要-fsanitize=address -g就可以，运行程序时候可以选择添加对应的ASAN_OPTIONS环境变量就可以检测出很多内存问题。它的错误信息也很有用，明确指出当前是什么类型的内存错误，如：

ITlover00

ITlover00

相关推荐

如何对Linux ps命令输出进行排序

ps命令是理解Linux系统上运行的内容和每个进程使用的资源的关键。了解如何显示ps以任何方式提供的信息都是非常有用的，这些信息可以帮助您集中精力解决您要解决的问题。这样做的一个方面是能够按任何列对ps aux命令的输出进行排序，以突出显示特定的信息，例如

farwang / 0评论 2020-11-25

如何在Fedora中安装VirtualBox

如果你对 Fedora Linux 感兴趣，这有几种方式可以尝试它。最简单还不影响你操作系统的方式是制作 Fedora 的 USB 临场启动盘。在 Linux 发行版的使用方式上，有一种可以无需安装而通过光盘或 USB 存储棒直接在计算机上启动完整的 Li

星愿心愿 / 0评论 2020-11-24

一篇带给你Linux磁盘管理和Shell编程

Linux磁盘管理常用三个命令为df、du和fdisk。列出文件系统的磁盘使用状况 - 「df」。磁盘分区表操作 - 「fdisk」。磁盘分区工具 - 「parted」。-c - 创建文件系统时检查磁盘损坏情况。-v - 显示详细信息。Shell脚本是一种

tianhuak / 0评论 2020-11-24

Linux日志文件系统原来是这样工作的

文件系统要解决的一个关键问题是怎样防止掉电或系统崩溃造成数据损坏，在此类意外事件中，导致文件系统损坏的根本原因在于写文件不是原子操作，因为写文件涉及的不仅仅是用户数据，还涉及元数据包括 Superblock、inode bitmap、inode、data

zhjn0 / 0评论 2020-11-24

Linux环境变量配置全攻略

在自定义安装软件的时候，经常需要配置环境变量，下面列举出各种对环境变量的配置方法。export命令显示当前系统定义的所有环境变量。这两个命令执行的效果如下。使用export命令直接修改PATH的值，配置MySQL进入环境变量的方法:. 配置的环境变量中不要

昭君出塞 / 0评论 2020-11-23

自动解锁Linux上的加密磁盘

通过使用网络绑定磁盘加密，无需手动输入密码即可打开加密磁盘。从安全的角度来看，对敏感数据进行加密以保护其免受窥探和黑客的攻击是很重要的。要使用 LUKS 配置加密磁盘或分区，你需要使用cryptsetup工具。然而，网络绑定磁盘加密Network-Boun

bluecarrot / 0评论 2020-11-23

Linux安装Nginx步骤详解

修改完成之后,重启nginx服务器.

liuchen0 / 0评论 2020-11-13

Linux安装Nginx步骤详解

修改完成之后,重启nginx服务器.

LUOPING0 / 0评论 2020-11-11

linux自动化交互脚本expect详解

expect脚本是Tcl脚本语言的拓展。用来实现自动的交互式任务，无需人为干预。在实际开发中，运行shell脚本有时候会输入linux密码或者是mysql密码等，而expect可以帮我们输入。timeout：timeout是expect脚本的内部变量，我们

linuxwcj / 0评论 2020-10-21

Linux Shell 如何获取参数的方法

是显示最后命令的退出状态，0表示没有错误，其他表示有错误。不同点：$* 和 $@ 都表示传递给函数或脚本的所有参数，不被双引号(" ")包含时，都以"$1" "$2" …"$n"

以梦为马不负韶华 / 0评论 2020-10-20

Linux Shell脚本中获取本机ip地址方法

ifconfig -a|grep inet|grep -v 127.0.0.1|grep -v inet6|awk '{print $2}'|tr -d "addr:". 假设某个机器有192.*.*.8和10.*.*.*网段的IP，现

彼岸随笔 / 0评论 2020-10-20

Linux 中shell脚本设置开头固定格式的实现方法

每次进入shell都要设置开头，很麻烦，现修改vim配置文件即可。之后新建一个shell ，开头就会有固定的格式。这是在root用户下的配置，切换到用户使用shell 可能还是什么都没有，不过一般都是用root用户进行机器的管理。不加sudo 没有权限进入

yutou0 / 0评论 2020-10-17

浅析Linux之bash反弹shell原理

反弹shell往往是在攻击者无法直接连接受害者的情况下进行的操作，原因有很多，例如目标是局域网，或者开启防火墙的某些策略等情况，而这时，我们就可以让受害者主动向攻击者发起连接，被控端发起请求到控制端某端口，并将其命令行的输入输出转到控制端，从而实现交互。L

applecarelte / 0评论 2020-10-16

linux反弹shell的原理详解

0代表输入 ，0>&1 意思是，将输出的窗口上所输入的值当作当前窗口的输入。反弹shell后会有两个窗口，即靶机的shell窗口跟攻击机的shell口。2代表标准错误输出。这是因为我们已经将所有的输出都重定向到了外部主机上，但问题是现在我们的

ourtimes / 0评论 2020-10-16

Linux 通过 autojump 命令减少 cd 命令的使用的实现方法

Linux - 通过 autojump 命令减少 cd 命令的使用。在文件的最后 追加一行。这行代码在你安装的时候， 软件会提示你的，你复制上去就行。路径前面的数字，就是这个路径的权重值，权重值高的，如果找到多个时，优先进去。通过 j s 简写就可以快速进

waterhorse / 0评论 2020-09-19

Linux下redis5.0.5的安装过程与配置方法

先将 redis-5.0.5 里的配置文件 redis.conf 移动到刚创建的 config 文件夹。 注释掉 bind 127.0.0.1 这一行。 将 protected-mode 属性改为 no

MRFENGG / 0评论 2020-11-11

Redis概述及linux安装redis的详细教程

性能极高，Redis能读的速度是110000次/s,写的速度是81000次/s 。Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set

rainandtear / 0评论 2020-10-30

linux 常见的标识与Redis数据库详解

第一个 xxx 只的是 用户名。第二个 xxx 代表的是 HOST主机。查看当前命令所在的位置。drwxr-xr-x 2 xxx xxx 4096 9月 1 18:37 公共的。第一列由10个字符组成，由 0-9 标识每一个字符。7-9: 其他用户所对应的

kyssfanhui / 0评论 2020-10-20

Aliyun Linux 编译安装 php7.3 tengine2.3.2 mysql8.0 redis5的过程详解

之前写过 CentOS 安装 PHP，MySQL，Nginx 的相关文章，具体介绍这里就不写了，直接上操作步骤.nginx rewrite依赖于PCRE库，所以在安装Tengine前一定要先安装PCRE，最新版本的PCRE可在官网获取。安装OpenSSL

liuhangtiant / 0评论 2020-10-20

linux mint下安装phpstorm2020包括JDK部分的教程详解

环境：linux mint 20,一切都是最新的版本。都知道，PHPSTORM破解和运行都是离不开JDK/JRE的。接下来，放心大胆的去官网下载phpstorm。解压到你想要的地方。现在可以愉快的使用ps了。

lonesomer / 0评论 2020-09-17

如何在Linux上检查可用的磁盘空间

在 Linux 上查找可用磁盘空间的最简单的方法是使用 df 命令。df命令从字面意思上代表着磁盘可用空间disk free，很明显，它将向你显示在 Linux 系统上的可用磁盘空间。使用-h选项，它将以人类可读的格式来显示磁盘空间。如果上面的输出使你感到

yegen00 / 0评论 2020-11-17

为什么 Linux 需要 Swapping 你知道吗？

为什么这么设计是一系列关于计算机领域中程序设计决策的文章，我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。Linux 提供了两种不同的方法启用 Swapping，分别是 Swap 分区和 Swap

Attend / 0评论 2020-11-17

Linux网络监控工具大点兵

网络通讯Linux中最基本基本的功能之一，很多是时候我们需要获取Linux的网络信息。Linux中存在很多网络监控工具，本文就给大家介绍一下，Linux常见的网络监控工具。Netstat是Linux下全能的网络监控工具，可以监控主机网络数据包统计信息以及网

kyssfanhui / 0评论 2020-11-16

Linux 不懂权限管理，怎么玩骚操作

本文转载自微信公众号「小菜良记」，作者蔡不菜丶。首先看到这个问题，小菜是有点懵的，为什么 Linux 是运维才需要精通的呢。话不多说，小菜这篇就带你来了解一下 Linux 中的 权限 是如何管理的，Linux 的基本操作可以查看这篇文章：Linux操作

ZHAICAN / 0评论 2020-11-16

如何在 Linux 上扫描/检测新的 LUN 和 SCSI 磁盘

当 Linux 系统连接到 SAN后，你需要重新扫描 iSCSI 服务以发现新的 LUN。要做到这一点，你必须向存储团队提供 Linux 主机的 WWN 号和所需的 LUN 大小。LUN 在存储术语中被称为 LUN 的串行十六进制。这可以通过两种方式进行，

codedecode / 0评论 2020-11-14

大神教你在Linux中查找和删除重复文件的4种方法

如果您习惯于从网络下载各种内容，则整理您的主目录甚至系统可能会特别困难。您可能会发现自己下载了相同的mp3，pdf，zip并将其复制到其他目录。在本教程中，您将学习如何使用rdfind和fdupes命令行工具以及称为DupeGuru和FSlint的GUI工

jimeshui / 0评论 2020-11-13

国内开源的里程碑！Linux基金会项目正式进入中国

近日,Linux 基金会和国内著名代码托管平台 Gitee 达成合作关系,将逐步在 Gitee 建立基金会旗下项目的官方镜像仓库,让国内开发者更近距离地认识和了解 Linux 基金会旗下项目,并参与其开源社区交流。在未来,会有更多 Linux 基金会项目

zhaomengsen / 0评论 2020-11-12

超级详细｜Linux系统下从0到1的玩法大全

Linux是一个开源、免费的操作系统，其稳定性、安全性、处理并发已经得到业界的认可，目前很多企业级的项目都会部署到Linux/unix系统上。Linux可以安装在各种计算机硬件设备中，比如手机、平板电脑、路由器、视频游戏控制、台式计算机、大型机和超级计算机

zhangbingb / 0评论 2020-11-12

为什么Linux内核常常用unsigned long来代替指针

不知道自己不知道!物理地址是指针?昨天我犯了一个错误把指针和整数“混淆”的错误，幸得队友王童鞋指正，今早起床，我把这个心得花一点时间记录下来。)，指针和整数在C语言里面是两种不同含义的：。所以指针的目的其实就是为了这样的读写操作：

hanjinixng00 / 0评论 2020-11-12

12款非常实用的Linux工具

本文介绍12款 Linux 运维比较实用的工具，希望对 Linux 运维人员有所帮助。Nethogs 是一个终端下的网络流量监控工具可以直观的显示每个进程占用的带宽。IOZone 是一款 Linux 文件系统性能测试工具 可以测试不同的操作系统中文件系统的

natejeams / 0评论 2020-11-11

Linux网络状态工具ss命令使用详解

ss命令用于显示socket状态. 他可以显示PACKET sockets, TCP sockets, UDP sockets, DCCP sockets, RAW sockets, Unix domain sockets等等统计. 它比其他工具展示等多t

ykmail / 0评论 2020-11-11

如何修复Linux中损坏的软件包？

它们都相当普遍，但是每种情况都不尽相同，因此试着自行解决问题时牢记这一点。Apt有几个标志，可用于修复安装过程中因某个原因而损坏的缺失的依赖项或软件包。这些依赖项可能不会自行获取，dpkg会抱怨缺少软件包。在后台负责这部分的是dpkg，而不是Apt，因此有

playlinuxxx / 0评论 2020-11-11

Linux监控进程并重启

保存shell 脚本，通过sh restart.sh运行 或者通过后台进程命令 ./restart.sh

拿什么来拯救自己 / 0评论 2020-11-11

Linux黑话解释：什么是Linux中的GUI、CLI和TUI？

当你开始使用 Linux 并关注关于 Linux 的网站和论坛时，你会经常遇到诸如 GUI、CLI 等术语，有时还会遇到 TUI。这一章的 Linux 黑话解释简要解释了这些术语，以便你作为一个（新的）Linux 用户在使用这些缩写词时能够更好地理解上下文

zhangm / 0评论 2020-11-10

一个令人惊叹的Linux内核补丁

本文转载自微信公众号「相遇Linux」，作者JeffXie。我们都知道linux内核中的代码非常精妙，但是有些代码由于历史原因，一个函数为了兼容处理各种情况，到最后可能变得非常糟糕，到处都是goto 和if，看的想跳楼。这个函数的功能是把磁盘中的数据读到

andyzhaojianhui / 0评论 2020-11-10

Linux内核5.10 LTS的一些令人兴奋的改进

Linux 内核 5.10 的开发正在进行中。已确认这是一个长期支持的版本，将带来更新的硬件支持和其他承诺的功能。主要稳定内核维护者Greg Kroah-Hartman在 Linux 基金会欧洲开源峰会的 “Ask the Expert” 环节上发言，确认

lufybrooklin / 0评论 2020-11-09

Linux Tcp 内核协议栈学习三种武器 之 Packet Drill

Linux TCP 内核协议栈是一个非常复杂的实现， 不但沉淀了过去20多年的设计与实现，同时还在不停的更新。相关的RFC与优化工作一直还在进行中。如何研究和学习Linux TCP内核协议栈这样一块硬骨头就成了一大难题。这个是最最基本的要求。幸运的是G

wangqd / 0评论 2020-11-09

Linux操作系统存储子系统核心技术之硬盘与RAID

在Linux的存储子系统中，最底层的就是硬盘了。这里的硬盘并不是指我们看到的硬盘硬件，而是指在Linux内部看到的硬盘设备，或者说是块设备。如果我们在/dev目录执行以下ls命令，就可以看到很多设备。在这些设备中以sd开头的就是基于SCSI协议的硬盘。无论

涅磐 / 0评论 2020-11-08

如何并发执行Linux命令

本文转载自微信公众号「Linux开发那些事儿」，作者LinuxThings 。在bash脚本中，并发执行命令的用途很多，比如：批量上传和下载，批量启动和关闭程序，批量打包日志，批量检查远程机器是否可达等等。并行下载是启动20个进程，20个进程同时下载，每个

大孩爱小孩 / 0评论 2020-11-06

记一次优化Linux服务器swap内存过高问题

今天收到zabbix告警，有点奇怪的是swap内存使用很高，但实际使用内存却不多，下面一起来看看吧：。正常情况下swap的使用应该是0，所以swap剩余小于80%时，我们便需要关注是哪个进程占用过高。如果内存够大，其实不必太多的使用 SWAP 分区， 可以

futurezone / 0评论 2020-11-06

Google Fuchsia操作系统分支：Linux发行版市场的新竞争者？

被传它将取代Android操作系统。我们已经有将近一年没有听到关于Google Fuchsia的消息了。目前，开发领域似乎也不活跃。Fuchsia是Google的一款实验性操作系统，它使用了新的Zicron内核，其主要目的是创建一个始终互联的设备生态系统

周末参见 / 0评论 2020-11-05

Linux系统服务(systemctl)的使用

查看服务有哪些依赖(反向) systemctl list-dependencies --reverse xx.service. 因为要重启一个新的服务，所以要修改一下ExecStart这一行，读取新的配置文件 sshd2_config，改为

Schvian / 0评论 2020-11-04

如何在Debian、Ubuntu中使用apt-cache命令

在本教程中学习使用 apt-cache 命令。元数据通常由包名、版本、描述、依赖关系、仓库和开发者等信息组成。令人惊讶的是，apt-cache并不能清除 APT 缓存。为此，你必须使用 apt-get clean 命令。不用说，APT 打包系统是在 Deb

菜鸟上路CCLinux / 0评论 2020-11-04

2020最受欢迎的Linux发行版Top 10

Ubuntu是南非巨富Mark Shuttleworth在Debian的基础上的开源操作系统。Ubuntu立足桌面，发行版质量，安全更新和可用性。Ubuntu采用常规版本和和LTS版本的发行策略。Ubuntu是目前使用最广泛和支持的Linux发行版之一。

rikeyone / 0评论 2020-11-04

Linux系统下对目录扩容的方法

卸载/home时 提示目标忙，fuser -m /home查看谁用/home时提示没有fuser命令。必须格式化/home分区，才能挂载----所以缩减/home分区之前必须备份/home的内容（切记！！！

橄榄 / 0评论 2020-11-04

一文理解 Linux 平均负载，附排查工具

平均负载可以对于我们来说及熟悉又陌生，但我们问平均负载是什么，但大部分人都回答说平均负载不就是单位时间内CPU使用率吗？其实并不是这样的，如果可以的话，可以 man uptime 来了解一下平均负载的详细信息。简单的说平均负载是指单位时间内，系统处于可运行

AnotherSpace / 0评论 2020-11-03

如何在Ubuntu Linux上释放/boot分区的空间？

前几天，我收到一个警告，/boot分区已经几乎满了，没有剩余空间了。是的，我有一个独立的/boot分区，我相信现在很少有人这样做了。（LCTT 译注：个人认为保留单独的 /boot 分区是个好的运维经验，除此以外，/tmp、/var 也单独划定分区比较好。

瑞风轻拂 / 0评论 2020-11-02

Linux黑话解释：什么是显示管理器？

在这篇 Linux 黑话解释中，你将了解 Linux 中的显示管理器。它的作用是什么？简单来说，显示管理器display manager是一个为你的 Linux 发行版提供图形登录功能的程序。它控制用户会话并管理用户认证。显示管理器会在你输入用户名和密码后

WenCoo / 0评论 2020-10-31

用这个创建可引导USB的工具在电脑上尝试Linux

Fedora Media Writer 是创建临场版 USB 以尝试 Linux 的方便方法。Fedora Media Writer是一个小巧、轻量、全面的工具，它简化了 Linux 的入门体验。它可以下载 Fedora 的 Workstation 或

一路到黑 / 0评论 2020-10-30

Fedora 33正式版发布！采用GNOME 3.38桌面、BTRFS文件系统

Fedora是基于Linux的开放操作系统和平台，日前，Fedora 33正式版发布，除了工作站、服务器版本之外，Fedora 33还推出了物联网版本。Fedora CoreOS是一个新兴的Fedora版本，它是一个自动更新的、最小化的操作系统，用于安全地

89437401 / 0评论 2020-10-29