Re: Coverity Open Source Defect Scan of PostgreSQL

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Coverity Open Source Defect Scan of PostgreSQL
Дата
Msg-id 20060307132830.GB4307@surnet.cl
обсуждение исходный текст
Ответ на Re: Coverity Open Source Defect Scan of PostgreSQL  (Neil Conway <neilc@samurai.com>)
Ответы Re: Coverity Open Source Defect Scan of PostgreSQL  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Neil Conway wrote:

> I'm a bit surprised to see that there are ~300 unfixed defects: AFAIR I
> fixed all the issues the EDB guys passed on to me, with the exception of
> some false positives and a handful of minor issues in ECPG that I
> couldn't be bothered fixing (frankly I would rather not touch the ECPG
> code). I've requested access to the Coverity results -- I'll be curious
> to see if we can get any more useful fixes from the tool.

It's not unlikely that the checker got improved.

FWIW I don't see any report related to the MemoryContext stuff, which I
was expecting we would be flooded with.  I haven't seen the entire list
yet, but they do make the mistake of not noticing that ereport(ERROR)
does not continue execution.  For example:

-------->-------->-------->-------->-------->-------->-------->-------->
pgsql/src/backend/optimizer/plan/createplan.c

638          foreach(l, uniq_exprs)
639          {
640              Node       *uniqexpr = lfirst(l);
641              TargetEntry *tle;
642      
643              tle = tlist_member(uniqexpr, newtlist);

Event var_compare_op: Added "tle" due to comparison "tle == 0"
Also see events: [var_deref_op]
At conditional (1): "tle == 0" taking true path

644              if (!tle)                /* shouldn't happen */
645                  elog(ERROR, "failed to find unique expression in subplan tlist");

Event var_deref_op: Variable "tle" tracked as NULL was dereferenced.
Also see events: [var_compare_op]

646              groupColIdx[groupColPos++] = tle->resno;
647          }
-------->-------->-------->-------->-------->-------->-------->-------->

We all know that this is not a bug.  There are lots of these, as you can
imagine.  

There are lots of other "not a bugs".  For example in initdb, there is a
lot of noise about how we don't free the resources.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Eduardo Morelli"
Дата:
Сообщение: Fw: Problemas with gram.y
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: pg_freespacemap question