Re: ECPG cleanup and fix for clang compile-time problem - Mailing list pgsql-hackers
From | Alexander Lakhin |
---|---|
Subject | Re: ECPG cleanup and fix for clang compile-time problem |
Date | |
Msg-id | 5f5bcecd-d7ec-b8c0-6c92-d1a7c6e0f639@gmail.com Whole thread Raw |
In response to | Re: ECPG cleanup and fix for clang compile-time problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: ECPG cleanup and fix for clang compile-time problem
|
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
pgsql-hackers by date: