[HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Andres Freund
==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:

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Greg Stark
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Andres Freund
On 2013-02-17 15:10:35 +, Greg Stark wrote: 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2013-02-17 15:10:35 +, Greg Stark wrote: 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.

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Boszormenyi Zoltan
2013-02-17 16:32 keltezéssel, Tom Lane írta: Andres Freund and...@2ndquadrant.com writes: On 2013-02-17 15:10:35 +, Greg Stark wrote: 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Tom Lane
Boszormenyi Zoltan z...@cybertec.at writes: Then, why isn't memcpy() skipped if the source and dest are the same? It would be a micro-optimization but a valid one. No, it'd be more like a micro-pessimization, because the test would be wasted effort in the vast majority of calls. The *only*

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Greg Stark
On Sun, Feb 17, 2013 at 4:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: No, it'd be more like a micro-pessimization, because the test would be wasted effort in the vast majority of calls. The *only* reason to do this would be to shut up valgrind, and that seems annoying. In terms of runtime I

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
Tom Lane t...@sss.pgh.pa.us schrieb: Andres Freund and...@2ndquadrant.com writes: On 2013-02-17 15:10:35 +, Greg Stark wrote: 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
Tom Lane t...@sss.pgh.pa.us schrieb: Boszormenyi Zoltan z...@cybertec.at writes: Then, why isn't memcpy() skipped if the source and dest are the same? It would be a micro-optimization but a valid one. No, it'd be more like a micro-pessimization, because the test would be wasted effort in the

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Peter Geoghegan
On 17 February 2013 18:52, anara...@anarazel.de and...@anarazel.de wrote: You already need a suppression file to use valgrind sensibly, its easy enough to add it there. Perhaps we should add one to the tree? Perhaps you should take the time to submit a proper Valgrind patch first. The current

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
Peter Geoghegan peter.geoghega...@gmail.com schrieb: On 17 February 2013 18:52, anara...@anarazel.de and...@anarazel.de wrote: You already need a suppression file to use valgrind sensibly, its easy enough to add it there. Perhaps we should add one to the tree? Perhaps you should take the time

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Andres Freund
On 2013-02-17 19:52:16 +, Peter Geoghegan wrote: On 17 February 2013 19:39, anara...@anarazel.de and...@anarazel.de wrote: What patch are you talking about? I have no knowledge about any pending valgrind patches except one I made upstream apply to make pg inside valgrind work on