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);
  

Tue, 08 Dec 1998 17:45:34 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
memory destruction in 6.4
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

Tue, 08 Dec 1998 11:32:52 +0200
Constantin Teodorescu <teo@flex.ro>
Re: [HACKERS] memory destruction in 6.4
>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

Tue, 08 Dec 1998 18:45:14 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] memory destruction in 6.4 
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, Pennsylvania 19026

Sat, 12 Dec 1998 23:37:38 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] memory destruction in 6.4
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, Pennsylvania 19026

Sat, 12 Dec 1998 23:42:07 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] memory destruction in 6.4u
> 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

Sun, 13 Dec 1998 20:14:28 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] memory destruction in 6.4 