Re: ECPG cleanup and fix for clang compile-time problem - Mailing list pgsql-hackers

Hello Tom,

14.10.2024 21:25, Tom Lane wrote:
> Attached are rebased and renumbered 0006-0008, mostly to keep the
> cfbot happy.  We could actually stop here, if we were feeling lazy,
> but now that I've done the work I'm inclined to push forward with
> the rest.
>
> The rest is just memory leak removal, and I suspect that nobody really
> cares that much about small leakage in the preprocessor: you'd have to
> be running some darn big files through it to notice.  FTR, here are
> the total leaks reported by valgrind for running the ecpg regression
> tests, using code like

Maybe you would like to fix in passing several (not new) defects, I've
found while playing with ecpg under Valgrind:
echo "
   EXEC SQL DECLARE cur1 CURSOR FOR stmt1;
" > t.pgc

valgrind  .../preproc/ecpg ... t.pgc

==831888== Conditional jump or move depends on uninitialised value(s)
==831888==    at 0x10C7B0: main (ecpg.c:490)
==831888==
char_array.pgc:2: WARNING: cursor "cur1" has been declared but not opened

Another case:
   EXEC SQL DECLARE cur_1 CURSOR FOR stmt_1;
   EXEC SQL FETCH cur_1 INTO :f1[[i];

==1335775==
==1335775== Conditional jump or move depends on uninitialised value(s)
==1335775==    at 0x121294: find_variable (variable.c:211)
==1335775==    by 0x11D661: base_yyparse (preproc.y:9749)
==1335775==    by 0x10C78F: main (ecpg.c:483)
==1335775==
==1335775== Conditional jump or move depends on uninitialised value(s)
==1335775==    at 0x121299: find_variable (variable.c:211)
==1335775==    by 0x11D661: base_yyparse (preproc.y:9749)
==1335775==    by 0x10C78F: main (ecpg.c:483)
==1335775==
==1335775== Invalid read of size 1
==1335775==    at 0x12128B: find_variable (variable.c:211)
==1335775==    by 0x11D661: base_yyparse (preproc.y:9749)
==1335775==    by 0x10C78F: main (ecpg.c:483)
==1335775==  Address 0x4e3bc80 is 0 bytes after a block of size 8,208 alloc'd
==1335775==    at 0x4848899: malloc (vg_replace_malloc.c:381)
==1335775==    by 0x120585: mm_alloc (util.c:87)
==1335775==    by 0x12065A: loc_alloc (util.c:151)
==1335775==    by 0x120701: loc_strdup (util.c:172)
==1335775==    by 0x10D9EC: base_yylex_location (parser.c:261)
==1335775==    by 0x10D4A1: filtered_base_yylex (parser.c:75)
==1335775==    by 0x114CA4: base_yyparse (preproc.c:39316)
==1335775==    by 0x10C78F: main (ecpg.c:483)
==1335775==
declare.pgc:2: ERROR: variable "f1" is not declared

One more case:
   EXEC SQL BEGIN DECLARE SECTION;
     int i;
   EXEC SQL END DECLARE SECTION;

   EXEC SQL DECLARE C CURSOR FOR SELECT 1;
   {
     EXEC SQL FETCH 1 IN C INTO :i;
   }
   EXEC SQL MOVE BACKWARD 1 IN C;

==961441== Invalid read of size 1
==961441==    at 0x484FBD7: strcmp (vg_replace_strmem.c:924)
==961441==    by 0x11442F: add_additional_variables (preproc.y:470)
==961441==    by 0x117DEF: base_yyparse (preproc.y:3548)
==961441==    by 0x10C78F: main (ecpg.c:483)
==961441==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

Best regards,
Alexander