| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> | 
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Amit Langote <amitlangote09(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: WIP Incremental JSON Parser | 
| Date: | 2024-04-08 00:58:36 | 
| Message-ID: | 3003849.1712537916@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Coverity complained that this patch leaks memory:
/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_combinebackup/load_manifest.c: 212 in load_backup_manifest()
206     			bytes_left -= rc;
207     			json_parse_manifest_incremental_chunk(
208     												  inc_state, buffer, rc, bytes_left == 0);
209     		}
210     
211     		close(fd);
>>>     CID 1596259:    (RESOURCE_LEAK)
>>>     Variable "inc_state" going out of scope leaks the storage it points to.
212     	}
213     
214     	/* All done. */
215     	pfree(buffer);
216     	return result;
217     }
/srv/coverity/git/pgsql-git/postgresql/src/bin/pg_verifybackup/pg_verifybackup.c: 488 in parse_manifest_file()
482     			bytes_left -= rc;
483     			json_parse_manifest_incremental_chunk(
484     												  inc_state, buffer, rc, bytes_left == 0);
485     		}
486     
487     		close(fd);
>>>     CID 1596257:    (RESOURCE_LEAK)
>>>     Variable "inc_state" going out of scope leaks the storage it points to.
488     	}
489     
490     	/* Done with the buffer. */
491     	pfree(buffer);
492     
493     	return result;
It's right about that AFAICS, and not only is the "inc_state" itself
leaked but so is its assorted infrastructure.  Perhaps we don't care
too much about that in the existing applications, but ISTM that
isn't going to be a tenable assumption across the board.  Shouldn't
there be a "json_parse_manifest_incremental_shutdown()" or the like
to deallocate all the storage allocated by the parser?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sutou Kouhei | 2024-04-08 01:01:17 | Re: meson: Specify -Wformat as a common warning flag for extensions | 
| Previous Message | Tom Lane | 2024-04-08 00:48:29 | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |