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

Commitc2d4eb1

Browse files
committed
Fix actual and potential double-frees around tuplesort usage.
tuplesort_gettupleslot() passed back tuples allocated in the tuplesort'sown memory context, even when the caller was responsible to free them.This created a double-free hazard, because some callers might destroythe tuplesort object (via tuplesort_end) before trying to clean up thelast returned tuple. To avoid this, change the API to specify that thetuple is allocated in the caller's memory context. v10 and HEAD alreadydid things that way, but in 9.5 and 9.6 this is a live bug that candemonstrably cause crashes with some grouping-set usages.In 9.5 and 9.6, this requires doing an extra tuple copy in some cases,which is unfortunate. But the amount of refactoring needed to avoid itseems excessive for a back-patched change, especially since the caseswhere an extra copy happens are less performance-critical.Likewise change tuplesort_getdatum() to return pass-by-reference Datumsin the caller's context not the tuplesort's context. There seem to beno live bugs among its callers, but clearly the same sort of situationcould happen in future.For other tuplesort fetch routines, continue to allocate the memory inthe tuplesort's context. This is a little inconsistent with what we nowdo for tuplesort_gettupleslot() and tuplesort_getdatum(), but that'spreferable to adding new copy overhead in the back branches where it'sclearly unnecessary. These other fetch routines provide the weakestpossible guarantees about tuple memory lifespan from v10 on, anyway,so this actually seems more consistent overall.Adjust relevant comments to reflect these API redefinitions.Arguably, we should change the pre-9.5 branches as well, but sincethere are no known failure cases there, it seems not worth the risk.Peter Geoghegan, per report from Bernd Helmle. Reviewed by KyotaroHoriguchi; thanks also to Andreas Seltenreich for extracting aself-contained test case.Discussion:https://postgr.es/m/1512661638.9720.34.camel@oopsware.de
1 parent1eb6d65 commitc2d4eb1

File tree

2 files changed

+13
-14
lines changed

2 files changed

+13
-14
lines changed

‎src/backend/utils/adt/orderedsetaggs.c

Lines changed: 1 addition & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -329,10 +329,7 @@ ordered_set_startup(FunctionCallInfo fcinfo, bool use_tuples)
329329
*
330330
* In the case where we're not expecting multiple finalfn calls, we could
331331
* arguably rely on the finalfn to clean up; but it's easier and more testable
332-
* if we just do it the same way in either case. Note that many of the
333-
* finalfns could *not* free the tuplesort object, at least not without extra
334-
* data copying, because what they return is a pointer to a datum inside the
335-
* tuplesort object.
332+
* if we just do it the same way in either case.
336333
*/
337334
staticvoid
338335
ordered_set_shutdown(Datumarg)

‎src/backend/utils/sort/tuplesort.c

Lines changed: 12 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -2147,12 +2147,13 @@ tuplesort_gettuple_common(Tuplesortstate *state, bool forward,
21472147
* NULL value in leading attribute will set abbreviated value to zeroed
21482148
* representation, which caller may rely on in abbreviated inequality check.
21492149
*
2150-
* If copy is true, the slot receives a copied tuple that will stay valid
2151-
* regardless of future manipulations of the tuplesort's state. Memory is
2152-
* owned by the caller. If copy is false, the slot will just receive a
2153-
* pointer to a tuple held within the tuplesort, which is more efficient, but
2154-
* only safe for callers that are prepared to have any subsequent manipulation
2155-
* of the tuplesort's state invalidate slot contents.
2150+
* If copy is true, the slot receives a tuple that's been copied into the
2151+
* caller's memory context, so that it will stay valid regardless of future
2152+
* manipulations of the tuplesort's state (up to and including deleting the
2153+
* tuplesort). If copy is false, the slot will just receive a pointer to a
2154+
* tuple held within the tuplesort, which is more efficient, but only safe for
2155+
* callers that are prepared to have any subsequent manipulation of the
2156+
* tuplesort's state invalidate slot contents.
21562157
*/
21572158
bool
21582159
tuplesort_gettupleslot(Tuplesortstate*state,boolforward,boolcopy,
@@ -2230,8 +2231,8 @@ tuplesort_getindextuple(Tuplesortstate *state, bool forward)
22302231
* Returns false if no more datums.
22312232
*
22322233
* If the Datum is pass-by-ref type, the returned value is freshly palloc'd
2233-
* and is now owned by the caller (this differs from similar routines for
2234-
* other types of tuplesorts).
2234+
*in caller's context,and is now owned by the caller (this differs from
2235+
*similar routines forother types of tuplesorts).
22352236
*
22362237
* Caller may optionally be passed back abbreviated value (on true return
22372238
* value) when abbreviation was used, which can be used to cheaply avoid
@@ -2253,6 +2254,9 @@ tuplesort_getdatum(Tuplesortstate *state, bool forward,
22532254
return false;
22542255
}
22552256

2257+
/* Ensure we copy into caller's memory context */
2258+
MemoryContextSwitchTo(oldcontext);
2259+
22562260
/* Record abbreviated key for caller */
22572261
if (state->sortKeys->abbrev_converter&&abbrev)
22582262
*abbrev=stup.datum1;
@@ -2269,8 +2273,6 @@ tuplesort_getdatum(Tuplesortstate *state, bool forward,
22692273
*isNull= false;
22702274
}
22712275

2272-
MemoryContextSwitchTo(oldcontext);
2273-
22742276
return true;
22752277
}
22762278

0 commit comments

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