The most disgusting Bug Nothing is better than stepping on memory , Anyone who has fixed the kernel problem knows it . This kind of problem has not been solved in a very routine way , You need to read a lot of code , Do a lot of debugging to solve this problem . Two key points in solving such problems are ,1, Find the memory address that was trampled on ,2, Grasp the time sequence of being trampled .
I want to find the memory address that was trampled on , A lot of times here you can disassemble through the stack , And debugging , Find out , Although a lot of times the place is not fixed , That's bad . We need to find ways to find common laws , For example, is it in the same global variable , Or in the same business scenario ?

    Here is a good method , If you know 1, Find the memory address that was trampled on ,2, Grasp the time sequence of being trampled . It can be used mprotect To help locate the problem .

#include <sys/mman.h> int mprotect(const void *addr, size_t len, int prot);
Since this function addr Starting , Count Reg len The protection property of the memory area of is modified to prot The specified value ,prot The values are as follows : prot Tag value   describe PROT_NONE The
memory cannot be accessedat all. PROT_READ The memory can be read. PROT_WRITE
The memory can be writtento. PROT_EXEC The memory can contain executing code.
Use this function in the code to protect the trampled address , If other modules or code try to write the operation , It'll hang up , And then there's a stack , Just follow the stack disassembly to find out where the memory has been stepped on .

©2019-2020 Toolsou All rights reserved,
os Simple use of module It's unexpected Python Cherry tree (turtle The gorgeous style of Library ) Browser kernel ( understand ) Some East 14 Pay change 16 salary , Sincerity or routine ?java Four functional interfaces ( a key , simple )html Writing about cherry trees , Writing about cherry trees HashMap Explain in detail