Introduction to common memory anomaly verification tools and methods under Linux

Introduction to common memory anomaly verification tools and methods under Linux

Exceptions caused by memory anomalies are often difficult to verify, and this article describes the verification tools and methods for various common memory anomalies under Linux.

1. Access null pointer/uninitialized pointer

This is the simplest memory exception, as long as the ability to generate coredump files, you can quickly locate the problem code.

Open Coredump

Coredump is not generated by default in some environments and requires the following command:
Ulimit-c Unlimited //unlimited means that the Coredump file size is not limited, or a maximum file size can be specified.

Customizing the core file name

The default Coredump file name is core, and if you want to customize the core file name yourself, you can run the following command:
echo "./core-%e-%p-%t" >/proc/sys/kernel/core_pattern
There are many more variables that can be used in the Core_pattern template, see the following list:
Percent of a single% character
Process ID of the%p dump process
The actual user ID of the%u dump process
%g The actual group ID of the dump process
%s causes the signal for this core dump
%t Core Dump time (number of seconds from January 1, 1970)
%H Host Name
%e program file name

Using GDB to locate code lines

Problem code

int main(){    int *p=0;    *p=6;    return 0;}

Run an exception after compiling with GCC-G and locate the line of error code through GDB

[email protected]:/home/zte/test# gcc null.cc -g[email protected]:/home/zte/test# ./a.out Segmentation fault (core dumped)[email protected]:/home/zte/test# gdb a.out core.......Core was generated by `./null‘.Program terminated with signal SIGSEGV, Segmentation fault.#0  0x00000000004004fd in main () at null.cc:44        *p=6;

2, Function Stack Overflow

A local variable's write-out may break the function stack frame and cause the program to Coredump, because the default is not to cross the first field coredump, resulting in a problem verification is very difficult.
Fortunately, we can easily locate the problem by using the GCC compile options-fstack-protector and-fstack-protector-all on the first scene where the function stack is destroyed.

Example

int main(){    int a=5;    int *p=&a;    p[3]=6;    return 0;}

The code above will break the function stack, and if we run it directly with GCC, it will not throw an exception. However, after the compilation parameters-fstack-protector and-fstack-protector-all are added, the run will throw an exception. Here is the result of the specific command execution.

[email protected]:/home/zte/test# gcc t.c[email protected]:/home/zte/test# ./a.out [email protected]:/home/zte/test# gcc t.c -fstack-protector -fstack-protector-all -g[email protected]:/home/zte/test# ./a.out *** stack smashing detected ***: ./a.out terminatedAborted (core dumped)

You can further use GDB's BT command to locate the problematic function.

  [email protected]:/home/zte/test# gdb a.out core ..... Core is generated by './a.out '. Program terminated with signal SIGABRT, aborted. #0 0x00007f6bcfab5c37 in __gi_raise ([email protected]=6] at: /nptl/sysdeps/unix/sysv/linux/raise.c:5656. /nptl/sysdeps/unix/sysv/linux/raise.c:no such file or directory. (GDB) bt#0 0x00007f6bcfab5c37 in __gi_raise ([email protected]=6) at: /nptl/sysdeps/unix/sysv/linux/raise.c:56#1 0x00007f6bcfab9028 in __gi_abort () @ abort.c:89#2 0x00007f6bcfaf22a4 in __ Libc_message ([Email protected]=1, [EMAIL&NBSP;PROTECTED]=0X7F6BCFC01D70 "* * * * * *%s * * *:%s terminated\n") at. /sysdeps/posix/libc_fatal.c:175#3 0x00007f6bcfb8d83c in __gi___fortify_fail (msg=<optimized out>, [email  PROTECTED]=0X7F6BCFC01D58 "stack smashing detected") at Fortify_fail.c:38#4 0x00007f6bcfb8d7e0 in __stack_chk_fail () At Stack_chk_fail.c:28#5 0X00000000004005AA in Main () at T.c:7 (gdb) q  

3. Cross-border read/write dynamic allocation memory/read/write released dynamically allocated memory

Dynamically allocated memory read/write out-of-bounds, read-write released dynamically allocated memory system by default it may not throw an exception, we can use electric-fence to make read-write out of bounds memory immediately throw exception, speed up the problem localization.

Installing electric fence

sudo apt-get install electric-fence

Using electric fence

The following is an out-of-bounds write code

#include <stdlib.h>int main(){    int *p = (int*)malloc(sizeof(int));    p[1] = 6;    return 0;}

If you run directly with GCC, you will not throw exceptions.
We can add parameter-lefence-g to run after compiling, throw exception. You can navigate to the problem code line by using GDB's BT print.

[email protected]:/home/zte/test# gcc malloc_read_free.cc -lefence -g[email protected]:/home/zte/test# ./a.out   Electric Fence 2.2 Copyright (C) 1987-1999 Bruce Perens <[email protected]>Segmentation fault (core dumped)

4. Dynamically allocating memory for repeated releases

Exceptions are thrown by default and can be located by GdB and Coredump.

Generated by Haroopad

This article is from "Wu-dong blog" blog, please be sure to keep this source http://13484557.blog.51cto.com/13474557/1983537

Description of common memory anomaly verification tools and methods under Linux