Horton

Re: ECPG cleanup and fix for clang compile-time problem

Alexander Law <exclusion@gmail.com>

View thread View on postgr.es
From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: John Naylor <johncnaylorls@gmail.com>, Peter Eisentraut <peter@eisentraut.org>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael.paquier@gmail.com>
Date: 2024-10-17T18:00:00Z
Lists: pgsql-hackers 
Hello Tom,

16.10.2024 19:26, Tom Lane wrote:
> Alexander Lakhin <exclusion@gmail.com> writes:
>> Maybe you would like to fix in passing several (not new) defects, I've
>> found while playing with ecpg under Valgrind:
> Done.  After evaluation I concluded that none of these were worth the
> trouble to back-patch, but by all means let's fix such things in HEAD.

Thank you for fixing these defects!

I've spent a day testing ecpg preprocessor and found another couple of
bugs:
1)
EXEC SQL BEGIN DECLARE SECTION;
int i = 1;
EXEC SQL END DECLARE SECTION;

EXEC SQL DECLARE c CURSOR FOR SELECT :i;

{;}
}

EXEC SQL OPEN c;

==1247560==
==1247560== Invalid read of size 4
==1247560==    at 0x121C13: dump_variables (variable.c:462)
==1247560==    by 0x10CF75: output_statement (output.c:157)
==1247560==    by 0x116B6B: base_yyparse (preproc.y:1233)
==1247560==    by 0x10C78F: main (ecpg.c:483)
==1247560==  Address 0x4e39bc0 is 16 bytes inside a block of size 32 free'd
==1247560==    at 0x484B27F: free (vg_replace_malloc.c:872)
==1247560==    by 0x1219AE: remove_variables (variable.c:351)
==1247560==    by 0x11899F: base_yyparse (preproc.y:7853)
==1247560==    by 0x10C78F: main (ecpg.c:483)
==1247560==  Block was alloc'd at
==1247560==    at 0x4848899: malloc (vg_replace_malloc.c:381)
==1247560==    by 0x120703: mm_alloc (util.c:87)
==1247560==    by 0x120C3C: new_variable (variable.c:12)
==1247560==    by 0x11C27C: base_yyparse (preproc.y:8984)
==1247560==    by 0x10C78F: main (ecpg.c:483)
...

---
2)
EXEC SQL BEGIN DECLARE SECTION;
char s[100];
EXEC SQL END DECLARE SECTION;

EXEC SQL DECLARE cur_1 CURSOR FOR SELECT 1;
EXEC SQL FETCH cur_1 INTO :s[0];

==1247848== Invalid read of size 4
==1247848==    at 0x121388: find_variable (variable.c:238)
==1247848==    by 0x11D684: base_yyparse (preproc.y:9751)
==1247848==    by 0x10C78F: main (ecpg.c:483)
==1247848==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

---
Also, processing of .../ecpg/test/sql/include.pgc, containing only:
EXEC SQL INCLUDE ../sql;

emits merely:
input in flex scanner failed

I think that's all that can be found here without extra efforts.

Best regards,
Alexander

Commits

  1. ecpg: clean up some other assorted memory leaks.

  2. ecpg: fix some memory leakage of data-type-related structures.

  3. ecpg: put all string-valued tokens returned by pgc.l in local storage.

  4. ecpg: fix more minor mishandling of bad input in preprocessor.

  5. ecpg: fix some minor mishandling of bad input in preprocessor.

  6. ecpg: avoid breaking the IDENT precedence level in two.

  7. ecpg: improve preprocessor's memory management.

  8. ecpg: move some functions into a new file ecpg/preproc/util.c.

  9. ecpg: re-implement preprocessor's string management.

  10. ecpg: major cleanup, simplification, and documentation of parse.pl.

  11. ecpg: remove check_rules.pl.

  12. ecpg: clean up documentation of parse.pl, and add more input checking.

  13. Clean up indentation and whitespace inconsistencies in ecpg.

  14. Exclude flex-generated code from coverage testing