X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 0BACAD1D597 for ; Fri, 13 Feb 2004 16:08:08 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 42426-02 for ; Fri, 13 Feb 2004 12:07:46 -0400 (AST) Received: from happy.onesystem.ca (happy.onesystem.ca [205.206.61.17]) by svr1.postgresql.org (Postfix) with ESMTP id 39735D1D298 for ; Fri, 13 Feb 2004 12:07:40 -0400 (AST) Received: from elb_lx.onesystem.ca ([10.1.1.50]) by happy.onesystem.ca with asmtp (Exim 4.14) id 1Arfqp-0001dw-5m; Fri, 13 Feb 2004 09:07:35 -0700 Subject: Re: ECPG Segfault and variable usage question. From: Edmund Bacon To: pgsql-interfaces Cc: =?ISO-8859-1?Q?J=FCrgen?= Cappel In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-lf7VEpXv7aafH78jkPDs" Message-Id: <1076688454.19238.12.camel@elb_lx.onesystem.ca> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 13 Feb 2004 09:07:34 -0700 X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/37 X-Sequence-Number: 4730 --=-lf7VEpXv7aafH78jkPDs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable An added data point for this bug I have seen a similar problem, although it seems to only manifest itself in long (1000+ line) source files. It seems to have something to do with using macros rather than explicit constants to define array dimensions. I'd be willing to bet that the below code example would compile by adding #define CL_2 (2*CHAR_LENGTH) ... char var[CL_2]; ... There seem to be 2 work arounds: either use a shorter macro name, or break long files into smaller pieces. On Thu, 2004-02-12 at 12:00, J=FCrgen Cappel wrote: > Hello, >=20 > this is a code snippet that causes ECPG to segfault. It's quite tricky > to produce, as changing the variable name from 'var' to 'myvar' already > causes things to compile fine ... >=20 >=20 > #define CHAR_LENGTH 25 > myfunction () > { > EXEC SQL BEGIN DECLARE SECTION; > char var[2*CHAR_LENGTH]; > EXEC SQL END DECLARE SECTION; >=20 > EXEC SQL DECLARE mycursor CURSOR FOR > SELECT att1, att2 > FROM mytable > WHERE att1 LIKE :var ESCAPE '\\'; > EXEC SQL OPEN mycursor; > } >=20 > Stack trace was obtained using a snapshot from about 2 weeks ago, ECPG fr= om > the 7.4.1 release segfaults also. >=20 > #0 0x4015fdcb in chunk_free () from /lib/libc.so.6 > #1 0x4015fc53 in free () from /lib/libc.so.6 > #2 0x080685b7 in dump_variables (list=3D0x80c1408, mode=3D1) at variable= .c:405 > #3 0x08066d56 in output_statement ( > stmt=3D0x80c14f8 "declare mycursor cursor for select att1 , att2 > from mytable where att1 like ? escape '\\\\' ", mode=3D0, con=3D0x0) at > output.c:126 > #4 0x0804af02 in yyparse () at preproc.y:780 > #5 0x0806671d in main (argc=3D8, argv=3D0xbffff264) at ecpg.c:409 > #6 0x401089ed in __libc_start_main () from /lib/libc.so.6 >=20 >=20 > Another problem that's giving me headaches trying to find a workaround for > is the following use of variables as data sources in INSERT/UPDATE > statements: >=20 > :myarray[index[10]] >=20 > Any comments, suggestions, hints ? Thanks a lot, >=20 > J=FCrgen >=20 >=20 > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend --=20 Edmund Bacon --=-lf7VEpXv7aafH78jkPDs Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit An added data point for this bug

I have seen a similar problem, although it seems to only manifest itself in long (1000+ line) source files.   It seems to have something to do with using macros rather than explicit constants to define array dimensions.  I'd be willing to bet that the below code example would compile by adding

#define CL_2   (2*CHAR_LENGTH)
...
   char var[CL_2];
...

There seem to be 2 work arounds: either use a shorter macro name, or break long files into smaller pieces.

On Thu, 2004-02-12 at 12:00, Jürgen Cappel wrote:
Hello,

this is a code snippet that causes ECPG to segfault. It's quite tricky
to produce, as changing the variable name from 'var' to 'myvar' already
causes things to compile fine ...


#define CHAR_LENGTH 25
myfunction ()
{
    EXEC SQL BEGIN DECLARE SECTION;
    char   var[2*CHAR_LENGTH];
    EXEC SQL END DECLARE SECTION;

    EXEC SQL DECLARE mycursor CURSOR FOR
	 SELECT att1, att2
	 FROM mytable
	 WHERE att1 LIKE :var ESCAPE '\\';
    EXEC SQL OPEN mycursor;
}

Stack trace was obtained using a snapshot from about 2 weeks ago, ECPG from
the 7.4.1 release segfaults also.

#0  0x4015fdcb in chunk_free () from /lib/libc.so.6
#1  0x4015fc53 in free () from /lib/libc.so.6
#2  0x080685b7 in dump_variables (list=0x80c1408, mode=1) at variable.c:405
#3  0x08066d56 in output_statement (
    stmt=0x80c14f8 "declare mycursor  cursor  for select  att1  , att2
from mytable where att1  like  ? escape '\\\\'  ", mode=0, con=0x0) at
output.c:126
#4  0x0804af02 in yyparse () at preproc.y:780
#5  0x0806671d in main (argc=8, argv=0xbffff264) at ecpg.c:409
#6  0x401089ed in __libc_start_main () from /lib/libc.so.6


Another problem that's giving me headaches trying to find a workaround for
is the following use of variables as data sources in INSERT/UPDATE
statements:

	:myarray[index[10]]

Any comments, suggestions, hints ?   Thanks a lot,

Jürgen


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
Edmund Bacon <ebacon@onesystem.com>
--=-lf7VEpXv7aafH78jkPDs--