1ANDROID MEMORY CHECKER COMPONENT 2 3The docs/ANDROID-MEMCHECK.TXT document contains description of a memory checker 4implemented in the emulator 5 6The memory checker is intended to catch simple memory access violations in the 7emulated system, including: 8- Memory leaks 9- Attempts to free / reallocate invalid pointers (including pointers that have 10 already been freed, or reallocated). 11- Attempts to read from / write to areas outside of allocated blocks. 12 13To provide this functionality, the memory checker works in conjunction with 14an instrumented version of libc.so library used by the emulated system. Both, 15emulator's memory checking, and libc's instrumentation are turned on by the 16-memcheck command-line option. If this argument is omitted, libc.so will run in 17the regular, not instrumented mode, and the emulator will not perform any 18actions related to the memory checking. 19 20The way emulator and instrumented libc.so work together is as such: 21libc.so hooks up every memory allocation call (malloc, free, calloc, realloc, 22and memalign). For each such call, libc sends a notification message to the 23emulator, providing an allocation descriptor that contains information about 24allocation block and operation that is being performed on this block. Emulator 25and libc use a "magic page" that is set up in such a way that every write to 26that page on the emulated system produces some sort of event in the emulator, 27allowing emulator to receive data that emulated system has written to the "magic 28page". For more info on that, see hw/goldfish-trace.c 29 30In response to events, received from libc.so, emulator keep tracks of all blocks 31that have been allocated from the heap on emulated system. Block descriptors are 32kept in a per-process basis, so when a process exits, emulator can list all the 33leaked blocks the process left behind. 34 35When a free, or realloc operation is performed on the emulated system, emulator 36can verify that the pointer passed to free/realloc matches the address of a 37block recorded in the current process' descriptors table. This way emulator can 38detect and report attempts to free/reallocate invalid pointers. 39 40To detect read/write violations, emulator uses prefix and suffix guarding areas 41that were added to the allocated blocks by the instrumented libc. To watch for 42access violations, emulator instruments ld_/st_mmu routines to verify that 43accessed memory doesn't belong to a guarding area of a block allocated in 44context of the current process. 45 46There are some tricky things like: 47- invalidating every page containing allocated blocks every time anything has 48 been read, or written to that page, so we can be sure that we don't miss AV 49 on condition that page has been cached and ld_/st_mmu is omitted when 50 accessing memory in that page. 51- Keeping track of each thread calling stack, so when access violation is 52 reported, we can pinpoint violation to precise location in the source code. 53- etc. 54 55All the code related to memory checking is guarded in emulator's code by 56CONFIG_MEMCHECK macro, making it easy to spot changes related to it in the 57sources. 58