From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Missing checks when malloc returns NULL... |
Date: | 2016-06-21 04:47:32 |
Message-ID: | CAB7nPqRu07Ot6iht9i9KRfYLpDaF2ZuUv5y_+72uP23ZAGysRg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
While auditing the code, I got surprised that there are a couple of
code paths that do nothing for this error handling:
- pg_regress and isolationtester use malloc extensively, in case of
failure those would just crash crash. I think that it matters for
buildfarm members that are under memory pressure to not do so, so
those should use pg_malloc instead.
- refint.c makes use of malloc to store plans in top memory context.
That's a buggy concept clearly... This code would need to be reworked
more largely than in the patch I attach.
- pg_dlsym for darwin uses malloc, but would crash on failure
- ps_status.c does nothing when it uses malloc().
- sprompt.c uses malloc once, and would crash on failure
- mcxt.c uses that, which is surprising:
@@ -704,7 +704,8 @@ MemoryContextCreate(NodeTag tag, Size size,
{
/* Special case for startup: use good ol' malloc */
node = (MemoryContext) malloc(needed);
- Assert(node != NULL);
+ if (node == NULL)
+ elog(PANIC, "out of memory");
}
I think that a PANIC is cleaner here instead of a simple crash.
So attached is a patch aimed at improving things. Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
malloc-nulls.patch | invalid/octet-stream | 6.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-06-21 04:59:53 | Re: Reviewing freeze map code |
Previous Message | Amit Kapila | 2016-06-21 04:32:03 | Re: parallel.c is not marked as test covered |