From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, wliang(at)stu(dot)xidian(dot)edu(dot)cn, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Report a potential memory leak in setup_config() |
Date: | 2022-02-16 04:30:07 |
Message-ID: | 3255493.1644985807@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> When I'd looked at this last I apparently (looking at git stash, I ended up
> discarding this) decided that the best way would be to change replace_token's
> API to one that just processes one line at a time, with an outer loop that
> processes all tokens in a line. I'm not really sure why anymore.
Hmm, I did it the other way, as attached. This gets it down to
==3254266== LEAK SUMMARY:
==3254266== definitely lost: 342 bytes in 17 blocks
==3254266== indirectly lost: 152 bytes in 2 blocks
==3254266== possibly lost: 0 bytes in 0 blocks
==3254266== still reachable: 2,403 bytes in 22 blocks
==3254266== suppressed: 0 bytes in 0 blocks
It seems that actually the pointer arrays *are* a big chunk of
the leakage, because the individual strings get freed in the
output loops! That's a bit ugly but I feel no need to change it.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
alternate-initdb-cleanup.patch | text/x-diff | 12.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | wliang | 2022-02-16 07:13:27 | Re: Report a potential memory leak in setup_config() |
Previous Message | Andres Freund | 2022-02-16 04:10:49 | Re: Report a potential memory leak in setup_config() |