Обсуждение: memory destruction in 6.4

Поиск
Список
Период
Сортировка

memory destruction in 6.4

От
Tatsuo Ishii
Дата:
While investigating a user's complaint, I have found some memory
destructions in 6.4 source using purify.

(1) parser/gram.y:fmtId()

It writes n+3 bytes into n+1 byte-long memory area if mixed case or
non-ascii identifiers given.

(2) catalog/index.c:

ATTRIBUTE_TUPLE_SIZE bytes are allocated but
sizeof(FormData_pg_attribute) bytes are written. Note that
ATTRIBUTE_TUPLE_SIZE is smaller than
sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
ATTRIBUTE_TUPLE_SIZE is 3 bytes smaller).

Attached patches try to fix the problem. I do not check all of sources 
and there may be similar mistakes remained, however.
--
Tatsuo Ishii
----------------------------- cut here -----------------------------------
*** postgresql-v6.4/src/backend/parser/gram.y.orig    Tue Dec  8 11:26:32 1998
--- postgresql-v6.4/src/backend/parser/gram.y    Tue Dec  8 11:27:00 1998
***************
*** 5125,5131 ****         if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;      if (*cp != '\0') {
!         cp = palloc(strlen(rawid)+1);         strcpy(cp,"\"");         strcat(cp,rawid);         strcat(cp,"\"");
--- 5125,5131 ----         if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;      if (*cp != '\0') {
!         cp = palloc(strlen(rawid)+3);         strcpy(cp,"\"");         strcat(cp,rawid);         strcat(cp,"\"");
*** postgresql-v6.4/src/backend/catalog/index.c.orig    Tue Dec  8 11:41:20 1998
--- postgresql-v6.4/src/backend/catalog/index.c    Tue Dec  8 14:14:29 1998
***************
*** 649,655 ****     value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);      init_tuple =
heap_addheader(Natts_pg_attribute,
!                                 sizeof *(indexRelation->rd_att->attrs[0]),                              (char *)
(indexRelation->rd_att->attrs[0]));     hasind = false;
 
--- 649,655 ----     value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);      init_tuple =
heap_addheader(Natts_pg_attribute,
!                     ATTRIBUTE_TUPLE_SIZE,                              (char *) (indexRelation->rd_att->attrs[0]));
  hasind = false;
 
***************
*** 689,695 ****          */         memmove(GETSTRUCT(cur_tuple),                 (char *) indexTupDesc->attrs[i],
!                 sizeof(FormData_pg_attribute));          value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);

--- 689,695 ----          */         memmove(GETSTRUCT(cur_tuple),                 (char *) indexTupDesc->attrs[i],
!                     ATTRIBUTE_TUPLE_SIZE);          value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);

Re: [HACKERS] memory destruction in 6.4

От
Constantin Teodorescu
Дата:
Tatsuo Ishii wrote:
> 
> While investigating a user's complaint, I have found some memory
> destructions in 6.4 source using purify.
> 
> (1) parser/gram.y:fmtId()
> 
> It writes n+3 bytes into n+1 byte-long memory area if mixed case or
> non-ascii identifiers given.

Could that be also the cause for the two bugs that I have been reported
some time ago occuring when object names contain spaces ?

PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel

THE FIRST ONE
=============
test=>create table students (id int4, name text); 
CREATE
test=> create view "my view" as select * from students;
CREATE
test=> select * from "my view";
ERROR:  nodeRead: Bad type 0 


THE SECOND ONE
==============
test=> create sequence student_id;
CREATE
test=> create table "my students" (id int4 default
nextval('student_id'), name text);
ERROR:  my: Table does not exist.

-- 
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Re: [HACKERS] memory destruction in 6.4

От
Tatsuo Ishii
Дата:
>Tatsuo Ishii wrote:
>> 
>> While investigating a user's complaint, I have found some memory
>> destructions in 6.4 source using purify.
>> 
>> (1) parser/gram.y:fmtId()
>> 
>> It writes n+3 bytes into n+1 byte-long memory area if mixed case or
>> non-ascii identifiers given.
>
>Could that be also the cause for the two bugs that I have been reported
>some time ago occuring when object names contain spaces ?
>
>PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel
>
>THE FIRST ONE
>=============
>test=>create table students (id int4, name text); 
>CREATE
>test=> create view "my view" as select * from students;
>CREATE
>test=> select * from "my view";
>ERROR:  nodeRead: Bad type 0 
>
>
>THE SECOND ONE
>==============
>test=> create sequence student_id;
>CREATE
>test=> create table "my students" (id int4 default
>nextval('student_id'), name text);
>ERROR:  my: Table does not exist.

Sorry, but my patches seem not to fix your problems.
--
Tatsuo Ishii

Re: [HACKERS] memory destruction in 6.4

От
Bruce Momjian
Дата:
Applied to both trees.



> While investigating a user's complaint, I have found some memory
> destructions in 6.4 source using purify.
> 
> (1) parser/gram.y:fmtId()
> 
> It writes n+3 bytes into n+1 byte-long memory area if mixed case or
> non-ascii identifiers given.
> 
> (2) catalog/index.c:
> 
> ATTRIBUTE_TUPLE_SIZE bytes are allocated but
> sizeof(FormData_pg_attribute) bytes are written. Note that
> ATTRIBUTE_TUPLE_SIZE is smaller than
> sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
> ATTRIBUTE_TUPLE_SIZE is 3 bytes smaller).
> 
> Attached patches try to fix the problem. I do not check all of sources 
> and there may be similar mistakes remained, however.
> --
> Tatsuo Ishii
> ----------------------------- cut here -----------------------------------
> *** postgresql-v6.4/src/backend/parser/gram.y.orig    Tue Dec  8 11:26:32 1998
> --- postgresql-v6.4/src/backend/parser/gram.y    Tue Dec  8 11:27:00 1998
> ***************
> *** 5125,5131 ****
>           if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;
>   
>       if (*cp != '\0') {
> !         cp = palloc(strlen(rawid)+1);
>           strcpy(cp,"\"");
>           strcat(cp,rawid);
>           strcat(cp,"\"");
> --- 5125,5131 ----
>           if (! (islower(*cp) || isdigit(*cp) || (*cp == '_'))) break;
>   
>       if (*cp != '\0') {
> !         cp = palloc(strlen(rawid)+3);
>           strcpy(cp,"\"");
>           strcat(cp,rawid);
>           strcat(cp,"\"");
> *** postgresql-v6.4/src/backend/catalog/index.c.orig    Tue Dec  8 11:41:20 1998
> --- postgresql-v6.4/src/backend/catalog/index.c    Tue Dec  8 14:14:29 1998
> ***************
> *** 649,655 ****
>       value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);
>   
>       init_tuple = heap_addheader(Natts_pg_attribute,
> !                                 sizeof *(indexRelation->rd_att->attrs[0]),
>                                (char *) (indexRelation->rd_att->attrs[0]));
>   
>       hasind = false;
> --- 649,655 ----
>       value[Anum_pg_attribute_attcacheoff - 1] = Int32GetDatum(-1);
>   
>       init_tuple = heap_addheader(Natts_pg_attribute,
> !                     ATTRIBUTE_TUPLE_SIZE,
>                                (char *) (indexRelation->rd_att->attrs[0]));
>   
>       hasind = false;
> ***************
> *** 689,695 ****
>            */
>           memmove(GETSTRUCT(cur_tuple),
>                   (char *) indexTupDesc->attrs[i],
> !                 sizeof(FormData_pg_attribute));
>   
>           value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);
>   
> --- 689,695 ----
>            */
>           memmove(GETSTRUCT(cur_tuple),
>                   (char *) indexTupDesc->attrs[i],
> !                     ATTRIBUTE_TUPLE_SIZE);
>   
>           value[Anum_pg_attribute_attnum - 1] = Int16GetDatum(i + 1);
>   
> 
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: [HACKERS] memory destruction in 6.4u

От
Bruce Momjian
Дата:
Added to TODO:
* views with spaces in view name fail when referenced


> Tatsuo Ishii wrote:
> > 
> > While investigating a user's complaint, I have found some memory
> > destructions in 6.4 source using purify.
> > 
> > (1) parser/gram.y:fmtId()
> > 
> > It writes n+3 bytes into n+1 byte-long memory area if mixed case or
> > non-ascii identifiers given.
> 
> Could that be also the cause for the two bugs that I have been reported
> some time ago occuring when object names contain spaces ?
> 
> PostgreSQL 6.4 on RedHat Linux i386, 2.0.36 Kernel
> 
> THE FIRST ONE
> =============
> test=>create table students (id int4, name text); 
> CREATE
> test=> create view "my view" as select * from students;
> CREATE
> test=> select * from "my view";
> ERROR:  nodeRead: Bad type 0 
> 
> 
> THE SECOND ONE
> ==============
> test=> create sequence student_id;
> CREATE
> test=> create table "my students" (id int4 default
> nextval('student_id'), name text);
> ERROR:  my: Table does not exist.
> 
> -- 
> Constantin Teodorescu
> FLEX Consulting Braila, ROMANIA
> 
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026

Re: [HACKERS] memory destruction in 6.4

От
Tatsuo Ishii
Дата:
> Applied to both trees.
> 
> 
> 
> > While investigating a user's complaint, I have found some memory
> > destructions in 6.4 source using purify.
> > 
> > (1) parser/gram.y:fmtId()
> > 
> > It writes n+3 bytes into n+1 byte-long memory area if mixed case or
> > non-ascii identifiers given.
> > 
> > (2) catalog/index.c:
> > 
> > ATTRIBUTE_TUPLE_SIZE bytes are allocated but
> > sizeof(FormData_pg_attribute) bytes are written. Note that
> > ATTRIBUTE_TUPLE_SIZE is smaller than
> > sizeof(FormData_pg_attribute). (for example, on solaris 2.6,
> > ATTRIBUTE_TUPLE_SIZE is 3 bytes smaller).
> > 
> > Attached patches try to fix the problem. I do not check all of sources 
> > and there may be similar mistakes remained, however.
> > --
> > Tatsuo Ishii

Thank you for taking care of my patches.
---
Tatsuo Ishii

Чтобы сделать работу с сайтом удобнее, мы используем cookie и аналитический сервис «Яндекс.Метрика». Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.