Re: BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pm91.arapov@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2025-03-17T08:26:43Z
Lists: pgsql-bugs
Attachments
- v3-0001-Fix-guc_malloc-calls-consistency-and-OOM-checks.patch (application/octet-stream) patch v3-0001
> On 16 Mar 2025, at 21:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> Those are all good points, I initially didn't think we should touch the
>> PGC_POSTMASTER cases but you are correct that avoiding back copy pastes to
>> happen is a Good Thing. The attached has all these fixes added.
>
> I think your fix in check_debug_io_direct is wrong:
>
> - *extra = guc_malloc(ERROR, sizeof(int));
> + *extra = guc_malloc(LOG, sizeof(int));
> + if (!*extra)
> + {
> + pfree(rawstring);
> + list_free(elemlist);
> + return false;
> + }
>
> It looks to me like rawstring and elemlist were already freed,
> so "return false" ought to be sufficient.
AFAICT it depends on the value of PG_O_DIRECT, but leaving them is the safe
option as they will be cleaned anyways.
> Also, in init_custom_variable maybe it'd be worth a comment,
> along the lines of
>
> - gen = (struct config_generic *) guc_malloc(ERROR, sz);
> + /* As above, OOM is fatal */
> + gen = (struct config_generic *) guc_malloc(FATAL, sz);
I was contemplating that but skipped it due to the really good comments in the
same function, but you are right that we might as well direct the reader.
--
Daniel Gustafsson
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix guc_malloc calls for consistency and OOM checks
- 8d48e84c5688 16.9 landed
- 8afec4ef67a2 17.5 landed
- 058b5152f02e 18.0 landed