Re: overlapping strncpy/memcpy errors via valgrind

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(at)2ndquadrant(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>