Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)
От | Tom Lane |
---|---|
Тема | Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) |
Дата | |
Msg-id | 17880.1471643725@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) (Piotr Stefaniak <postgres@piotr-stefaniak.me>) |
Ответы |
Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and
prevent information disclosure)
Re: Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure) |
Список | pgsql-hackers |
Piotr Stefaniak <postgres@piotr-stefaniak.me> writes: > On 2016-08-18 20:02, Heikki Linnakangas wrote: >>> - block = (AllocBlock) malloc(blksize); >>> + block = (AllocBlock) calloc(1, blksize); >> I think this goes too far. You're zeroing all palloc'd memory, even if >> it's going to be passed to palloc0(), and zeroed there. It might even >> silence legitimate warnings, if there's code somewhere that does >> palloc(), and accesses some of it before initializing. Plus it's a >> performance hit. > I just did a test where I [ this n that ] I think you are failing to understand Heikki's point. There is no way we are committing the change depicted above, because (1) it will mask more bugs than it fixes; (2) it's an enormously expensive way to fix anything; and (3) it will effectively disable valgrind testing for missed initializations. The right thing to do is find out what downstream bit of code is missing initializing a block of memory it's working on, and fix that localized oversight. It'd be useful also to figure out why our existing valgrind testing has not caught this already. The example you give looks like it surely ought to be replicated well enough in the standard regression tests. regards, tom lane
В списке pgsql-hackers по дате отправления: