From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 13:29:57 |
Message-ID: | bb451293-2a16-4b62-9d55-d2d967284fb2@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-04-07 Su 20:58, Tom Lane wrote:
> 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?
yeah, probably. Will work on it.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2024-04-08 13:31:22 | RE: Synchronizing slots from primary to standby |
Previous Message | Robert Haas | 2024-04-08 13:26:09 | Re: PostgreSQL 17 Release Management Team & Feature Freeze |