Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit1e0dfd1

Browse files
Add Valgrind buffer access instrumentation.
Teach Valgrind memcheck to maintain the "defined-ness" of each sharedbuffer based on whether the backend holds at least one pin at the pointit is accessed by access method code. Bugs like the one fixed by commitb0229f2 can be detected using this new instrumentation.Note that backends running with Valgrind naturally have their ownindependent ideas about whether any given byte in shared memory is safeor unsafe to access. There is no risk that concurrent access bymultiple backends to the same shared memory will confuse Valgrind'sinstrumentation, because everything already works at the process level(or at the memory mapping level, if you prefer).Author: Álvaro Herrera, Peter GeogheganReviewed-By: Anastasia LubennikovaDiscussion:https://postgr.es/m/20150723195349.GW5596@postgresql.orgDiscussion:https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpWRUb_45eexLH1+k2_Q@mail.gmail.com
1 parentf009591 commit1e0dfd1

File tree

2 files changed

+25
-6
lines changed

2 files changed

+25
-6
lines changed

‎src/backend/storage/buffer/bufmgr.c

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,7 @@
4949
#include"storage/proc.h"
5050
#include"storage/smgr.h"
5151
#include"storage/standby.h"
52+
#include"utils/memdebug.h"
5253
#include"utils/ps_status.h"
5354
#include"utils/rel.h"
5455
#include"utils/resowner_private.h"
@@ -1633,6 +1634,13 @@ PinBuffer(BufferDesc *buf, BufferAccessStrategy strategy)
16331634
buf_state))
16341635
{
16351636
result= (buf_state&BM_VALID)!=0;
1637+
1638+
/*
1639+
* If we successfully acquired our first pin on this buffer
1640+
* within this backend, mark buffer contents defined
1641+
*/
1642+
if (result)
1643+
VALGRIND_MAKE_MEM_DEFINED(BufHdrGetBlock(buf),BLCKSZ);
16361644
break;
16371645
}
16381646
}
@@ -1683,6 +1691,13 @@ PinBuffer_Locked(BufferDesc *buf)
16831691
*/
16841692
Assert(GetPrivateRefCountEntry(BufferDescriptorGetBuffer(buf), false)==NULL);
16851693

1694+
/*
1695+
* Buffer can't have a preexisting pin, so mark its page as defined to
1696+
* Valgrind (this is similar to the PinBuffer() case where the backend
1697+
* doesn't already have a buffer pin)
1698+
*/
1699+
VALGRIND_MAKE_MEM_DEFINED(BufHdrGetBlock(buf),BLCKSZ);
1700+
16861701
/*
16871702
* Since we hold the buffer spinlock, we can update the buffer state and
16881703
* release the lock in one operation.
@@ -1728,6 +1743,9 @@ UnpinBuffer(BufferDesc *buf, bool fixOwner)
17281743
uint32buf_state;
17291744
uint32old_buf_state;
17301745

1746+
/* Mark undefined, now that no pins remain in backend */
1747+
VALGRIND_MAKE_MEM_NOACCESS(BufHdrGetBlock(buf),BLCKSZ);
1748+
17311749
/* I'd better not still hold any locks on the buffer */
17321750
Assert(!LWLockHeldByMe(BufferDescriptorGetContentLock(buf)));
17331751
Assert(!LWLockHeldByMe(BufferDescriptorGetIOLock(buf)));

‎src/include/pg_config_manual.h

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -269,12 +269,13 @@
269269
/*
270270
* Include Valgrind "client requests", mostly in the memory allocator, so
271271
* Valgrind understands PostgreSQL memory contexts. This permits detecting
272-
* memory errors that Valgrind would not detect on a vanilla build. See also
273-
* src/tools/valgrind.supp. "make installcheck" runs 20-30x longer under
274-
* Valgrind. Note that USE_VALGRIND slowed older versions of Valgrind by an
275-
* additional order of magnitude; Valgrind 3.8.1 does not have this problem.
276-
* The client requests fall in hot code paths, so USE_VALGRIND also slows
277-
* native execution by a few percentage points.
272+
* memory errors that Valgrind would not detect on a vanilla build. It also
273+
* enables detection of buffer accesses that take place without holding a
274+
* buffer pin. See also src/tools/valgrind.supp.
275+
*
276+
* "make installcheck" is significantly slower under Valgrind. The client
277+
* requests fall in hot code paths, so USE_VALGRIND slows native execution by
278+
* a few percentage points even when not run under Valgrind.
278279
*
279280
* You should normally use MEMORY_CONTEXT_CHECKING with USE_VALGRIND;
280281
* instrumentation of repalloc() is inferior without it.

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp