Peter G is sitting near me and reminded me that this issue came up in the past. Iirc the conclusion then is that we're calling memcpy where the source and destination pointers are sometimes identical. Tom decided there was really no realistic architecture where that wouldn't work. We're not calling it on overlapping nonidentical pointers.
On Feb 17, 2013 2:22 PM, "Andres Freund" <
andres@2ndquadrant.com> wrote:
==24373== Source and destination overlap in strncpy(0x28b892f5, 0x28b892f5, 64)
==24373== at 0x402A8F2: strncpy (mc_replace_strmem.c:477)
==24373== by 0x7D563F: namestrcpy (name.c:221)
==24373== by 0x46DF31: TupleDescInitEntry (tupdesc.c:473)
==24373== by 0x889EC3: resolve_polymorphic_tupdesc (funcapi.c:573)
==24373== by 0x889873: internal_get_result_type (funcapi.c:322)
==24373== by 0x8896A2: get_expr_result_type (funcapi.c:235)
==24373== by 0x594577: addRangeTableEntryForFunction (parse_relation.c:1206)
==24373== by 0x57D81E: transformRangeFunction (parse_clause.c:550)
==24373== by 0x57DBE1: transformFromClauseItem (parse_clause.c:658)
==24373== by 0x57CF01: transformFromClause (parse_clause.c:120)
==24373== by 0x54F9A5: transformSelectStmt (analyze.c:925)
==24373== by 0x54E4E9: transformStmt (analyze.c:242)
==24373== Source and destination overlap in memcpy(0x546abc0, 0x546abc0, 24)
==24373== at 0x402B930: memcpy (mc_replace_strmem.c:883)
==24373== by 0x853BAB: uniqueentry (tsvector.c:127)
==24373== by 0x8541A5: tsvectorin (tsvector.c:262)
==24373== by 0x888781: InputFunctionCall (fmgr.c:1916)
==24373== by 0x888A7D: OidInputFunctionCall (fmgr.c:2047)
==24373== by 0x59B6D7: stringTypeDatum (parse_type.c:592)
==24373== by 0x580E14: coerce_type (parse_coerce.c:303)
==24373== by 0x580AD4: coerce_to_target_type (parse_coerce.c:101)
==24373== by 0x58B802: transformTypeCast (parse_expr.c:2222)
==24373== by 0x587484: transformExprRecurse (parse_expr.c:208)
==24373== by 0x587156: transformExpr (parse_expr.c:116)
==24373== by 0x5975CC: transformTargetEntry (parse_target.c:94)
I didn't check out the tsvector case but the
resolve_polymorphic_tupdesc/TupleDescInitEntry is clearly bogusly coded.
Do we care? strncpy'ing a string over itself isn't defined...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
