Re: unchecked malloc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: unchecked malloc
Date: 2005-09-27 05:03:25
Message-ID: 7684.1127797405@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> There are several places in both backend and tools that forget to check the
> return value of malloc(). For example(8.0.1),

> backend/port/dynloader/beos.c/pg_dlopen()

Dead port, probably not worth fixing.

> backend/bootstrap/bootstrap.c/AddStr()

This code will never be run under memory pressure, so although
it theoretically should be fixed, I'm having a hard time getting
excited about it. In any case palloc would be the correct fix.

> port/strdup.c/strdup()

Definitely broken; I just fixed it to conform to the SUS
http://www.opengroup.org/onlinepubs/007908799/xsh/strdup.html
(of course, this code isn't used on any remotely modern
platform, so it's probably not very relevant...)

> bin/pg_dump/common.c/findParentsByOid()

Probably should be fixed, although if pg_dump runs out of memory
it's just gonna fail anyway.

> To report the "out of memory" error, we should differenciate if
> ErrorContext is already set up.

No, because you're thinking in terms of the backend environment, and
generally in the backend the answer to "when to use malloc directly"
is "never". The client-side tools are the only place where this is
a serious question, and offhand I'd say "gripe to stderr and exit(1)"
is going to be the right answer in all cases there.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ron Peacetree 2005-09-27 05:09:19 Re: [PERFORM] A Better External Sort?
Previous Message Joshua D. Drake 2005-09-27 04:54:46 Re: State of support for back PG branches