1/*-------------------------------------------------------------------------
2 *
3 * memdebug.c
4 * Declarations used in memory context implementations, not part of the
5 * public API of the memory management subsystem.
6 *
7 *
8 * Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
9 * Portions Copyright (c) 1994, Regents of the University of California
10 *
11 * src/backend/utils/mmgr/memdebug.c
12 *
13 *
14 * About CLOBBER_FREED_MEMORY:
15 *
16 * If this symbol is defined, all freed memory is overwritten with 0x7F's.
17 * This is useful for catching places that reference already-freed memory.
18 *
19 * About MEMORY_CONTEXT_CHECKING:
20 *
21 * Since we usually round request sizes up to the next power of 2, there
22 * is often some unused space immediately after a requested data area.
23 * Thus, if someone makes the common error of writing past what they've
24 * requested, the problem is likely to go unnoticed ... until the day when
25 * there *isn't* any wasted space, perhaps because of different memory
26 * alignment on a new platform, or some other effect. To catch this sort
27 * of problem, the MEMORY_CONTEXT_CHECKING option stores 0x7E just beyond
28 * the requested space whenever the request is less than the actual chunk
29 * size, and verifies that the byte is undamaged when the chunk is freed.
30 *
31 *
32 * About USE_VALGRIND and Valgrind client requests:
33 *
34 * Valgrind provides "client request" macros that exchange information with
35 * the host Valgrind (if any). Under !USE_VALGRIND, memdebug.h stubs out
36 * currently-used macros.
37 *
38 * When running under Valgrind, we want a NOACCESS memory region both before
39 * and after the allocation. The chunk header is tempting as the preceding
40 * region, but mcxt.c expects to able to examine the standard chunk header
41 * fields. Therefore, we use, when available, the requested_size field and
42 * any subsequent padding. requested_size is made NOACCESS before returning
43 * a chunk pointer to a caller. However, to reduce client request traffic,
44 * it is kept DEFINED in chunks on the free list.
45 *
46 * The rounded-up capacity of the chunk usually acts as a post-allocation
47 * NOACCESS region. If the request consumes precisely the entire chunk,
48 * there is no such region; another chunk header may immediately follow. In
49 * that case, Valgrind will not detect access beyond the end of the chunk.
50 *
51 * See also the cooperating Valgrind client requests in mcxt.c.
52 *
53 *-------------------------------------------------------------------------
54 */
55
56#include "postgres.h"
57
58#include "utils/memdebug.h"
59
60#ifdef RANDOMIZE_ALLOCATED_MEMORY
61
62/*
63 * Fill a just-allocated piece of memory with "random" data. It's not really
64 * very random, just a repeating sequence with a length that's prime. What
65 * we mainly want out of it is to have a good probability that two palloc's
66 * of the same number of bytes start out containing different data.
67 *
68 * The region may be NOACCESS, so make it UNDEFINED first to avoid errors as
69 * we fill it. Filling the region makes it DEFINED, so make it UNDEFINED
70 * again afterward. Whether to finally make it UNDEFINED or NOACCESS is
71 * fairly arbitrary. UNDEFINED is more convenient for SlabRealloc(), and
72 * other callers have no preference.
73 */
74void
75randomize_mem(char *ptr, size_t size)
76{
77 static int save_ctr = 1;
78 size_t remaining = size;
79 int ctr;
80
81 ctr = save_ctr;
82 VALGRIND_MAKE_MEM_UNDEFINED(ptr, size);
83 while (remaining-- > 0)
84 {
85 *ptr++ = ctr;
86 if (++ctr > 251)
87 ctr = 1;
88 }
89 VALGRIND_MAKE_MEM_UNDEFINED(ptr - size, size);
90 save_ctr = ctr;
91}
92
93#endif /* RANDOMIZE_ALLOCATED_MEMORY */
94