Обсуждение: memory destruction in 6.4
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);
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
>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
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
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
> 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