overlapping strncpy/memcpy errors via valgrind

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: overlapping strncpy/memcpy errors via valgrind
Date: 2013-02-17 14:22:10
Message-ID: 20130217142209.GA5073@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

==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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2013-02-17 14:33:08 Re: JSON Function Bike Shedding
Previous Message Joachim Wieland 2013-02-17 12:55:46 posix_fadvise missing in the walsender