Re: memory-related bugs
От | Daniel Farina |
---|---|
Тема | Re: memory-related bugs |
Дата | |
Msg-id | CAAZKuFa5d97n7XdfVRWDLhB41AYQ+32cYSOov6HRFfG9jw4mXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: memory-related bugs (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Sep 8, 2011 at 1:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Farina <daniel@heroku.com> writes: >> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> I'm still of the opinion that there's no real need to avoid memcpy with >>> identical source and destination, so I didn't apply this first patch. > >> I am leery of memcpy with overlapping regions. I know that it can >> cause an infinite loop on ssse3 architectures, having to do with some >> backwards-iteration it does: >> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/609290 > > The linked page offers no support for your claim of an infinite loop, > and in any case it's discussing a case involving *overlapping* regions, > not *identical* regions. What do you mean? As per my original bug report, or in this case (possibly both; I should have dumped the registers, which I'll do if I see it again...)? I'm able to believe that things are fine with all known memcpys today in this case. > The reason why this concern is irrelevant for identical regions is that > no matter what order the memcpy routine copies the bytes in, it's > necessarily storing the exact same data into each byte that was there > before. The only way that strange results could be produced is if the > routine transiently set some byte to a value other than its final value, > which would mean that it must be intending to store to that location > more than once, which would be silly and inefficient. This is a good point, I do understand there is a distinction between the degenerate-case memcpy-to-identical region and the overlapping-case. In my naivety, I'd ask what the costs are of pedantic adherence to this common guideline and, in event someone somewhere does something that is not expected (or, has a slow-but-not-technically-buggy memcpy) are broken, how likely the failure will be easy to pick out. But I don't seriously expect an answer, because I don't think this code path has been a problem for so many years and measuring those things are pretty hard. -- fdr
В списке pgsql-hackers по дате отправления: