Thread
-
write past chunk end in ExprContext / to_char
Patrick Welche <prlw1@newn.cam.ac.uk> — 2007-06-28T18:16:51Z
With today's CVS code (originally noticed with 8.2beta3), on a PC where INT_MAX=0x7FFFFFFF=2147483647 postgres=# select version(); version --------------------------------------------------------------------------------------------------------------------------------- PostgreSQL 8.3devel on i386-unknown-netbsdelf4.99.20, compiled by GCC gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1 20070603) (1 row) postgres=# select to_char(2147483647,'999,999,999'); to_char -------------- ###,###,### (1 row) postgres=# select to_char(2147483648,'999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char -------------- ###,###,### (1 row) postgres=# select to_char(2147483648,'99,999,999'); to_char ------------- ##,###,### (1 row) postgres=# select to_char(2147483648,'9,999,999,999'); to_char ---------------- 2,147,483,648 (1 row) postgres=# select to_char(1234567890123,'999,999,999,999'); WARNING: detected write past chunk end in ExprContext 0x845509c WARNING: detected write past chunk end in ExprContext 0x845509c to_char ------------------ ###,###,###,### (1 row) postgres=# select to_char(1234567890123,'99,999,999,999'); to_char ----------------- ##,###,###,### (1 row) So strangely, to get the worrying WARNING, I seem to need >INT_MAX with a format string with 1 less positions than necessary - no wonder I seemed to only see it randomly... Thoughts? Cheers, Patrick -
Re: write past chunk end in ExprContext / to_char
Alvaro Herrera <alvherre@commandprompt.com> — 2007-06-28T18:29:12Z
Patrick Welche wrote: > With today's CVS code (originally noticed with 8.2beta3), on a PC where > INT_MAX=0x7FFFFFFF=2147483647 > > postgres=# select to_char(1234567890123,'999,999,999,999'); > WARNING: detected write past chunk end in ExprContext 0x845509c > WARNING: detected write past chunk end in ExprContext 0x845509c > to_char > ------------------ > ###,###,###,### > (1 row) Yes, it fails in 7.3, 7.4, 8.0, 8.1, 8.2 and HEAD. Thanks for the report. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "Executive Executive Summary: The [Windows] Vista Content Protection specification could very well constitute the longest suicide note in history." Peter Guttman, http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt -
Re: write past chunk end in ExprContext / to_char
Tom Lane <tgl@sss.pgh.pa.us> — 2007-06-28T19:09:38Z
Patrick Welche <prlw1@newn.cam.ac.uk> writes: > With today's CVS code (originally noticed with 8.2beta3), on a PC where > INT_MAX=0x7FFFFFFF=2147483647 > postgres=# select to_char(2147483648,'999,999,999'); > WARNING: detected write past chunk end in ExprContext 0x845509c > WARNING: detected write past chunk end in ExprContext 0x845509c Yech ... it's scribbling on the output of int8out, which is bad enough, but it's assuming that buffer will be long enough when it demonstrably isn't. Some days I think we ought to throw out formatting.c and rewrite it from scratch; it's probably the most poorly-coded module in all of Postgres. regards, tom lane
-
Re: write past chunk end in ExprContext / to_char
imad <immaad@gmail.com> — 2007-06-28T19:53:31Z
This is the problematic part in formatting.c, function "dch_time". int siz = strlen(tmtcTzn(tmtc)); if (arg == DCH_TZ) strcpy(inout, tmtcTzn(tmtc)); else { char *p = palloc(siz); strcpy(p, tmtcTzn(tmtc)); strcpy(inout, str_tolower(p)); pfree(p); } return siz; here, doing a palloc with "siz+1" solves the issue but following / making the convention, pstrdup should be used instead which is specifically written for this purpose. Probably too small a change for a patch ? --Imad www.EnterpriseDB.com On 6/29/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > With today's CVS code (originally noticed with 8.2beta3), on a PC where > > INT_MAX=0x7FFFFFFF=2147483647 > > > postgres=# select to_char(2147483648,'999,999,999'); > > WARNING: detected write past chunk end in ExprContext 0x845509c > > WARNING: detected write past chunk end in ExprContext 0x845509c > > Yech ... it's scribbling on the output of int8out, which is bad enough, > but it's assuming that buffer will be long enough when it demonstrably > isn't. > > Some days I think we ought to throw out formatting.c and rewrite it from > scratch; it's probably the most poorly-coded module in all of Postgres. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -
Re: write past chunk end in ExprContext / to_char
Tom Lane <tgl@sss.pgh.pa.us> — 2007-06-29T00:25:46Z
imad <immaad@gmail.com> writes: > This is the problematic part in formatting.c, function "dch_time". > int siz = strlen(tmtcTzn(tmtc)); > > if (arg == DCH_TZ) > strcpy(inout, tmtcTzn(tmtc)); > else > { > char *p = palloc(siz); > > strcpy(p, tmtcTzn(tmtc)); > strcpy(inout, str_tolower(p)); > pfree(p); > } > return siz; Hmm. That was not the buffer overrun I was looking at, but it sure looks like another one :-(. Thanks for spotting it! regards, tom lane -
Re: write past chunk end in ExprContext / to_char
Bruce Momjian <bruce@momjian.us> — 2007-06-29T02:41:14Z
Tom Lane wrote: > Patrick Welche <prlw1@newn.cam.ac.uk> writes: > > With today's CVS code (originally noticed with 8.2beta3), on a PC where > > INT_MAX=0x7FFFFFFF=2147483647 > > > postgres=# select to_char(2147483648,'999,999,999'); > > WARNING: detected write past chunk end in ExprContext 0x845509c > > WARNING: detected write past chunk end in ExprContext 0x845509c > > Yech ... it's scribbling on the output of int8out, which is bad enough, > but it's assuming that buffer will be long enough when it demonstrably > isn't. > > Some days I think we ought to throw out formatting.c and rewrite it from > scratch; it's probably the most poorly-coded module in all of Postgres. Agreed from personal experience. I am in there wacking it around it seems every release. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +