From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unlikely-to-happen crash in ecpg driver caused by NULL-pointer check not done |
Date: | 2015-02-03 13:44:17 |
Message-ID: | CAB7nPqS-oWUbRjPwzFm9WtEK0j-6pVvHT=hTErBh56tDdn=-rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 3, 2015 at 7:50 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Hmm. Since the ecpg_add_mem call is done after setting (*(void **) var),
> that's left to point to already-free'd memory. The other call sites have a
> similar issue. I haven't analyzed the code to check if that's harmless or
> not, but seems better to not do that.
Right, it is an error do allocate this memory if there is a risk that
it may be freed. Hence fixed.
> In ecpg_add_mem, the ecpg_raise() call is unnecessary, since ecpg_alloc
> already does that on failure.
Right, check.
> (It would be less error-prone to have an ecpg_alloc_auto() function that
> combines ecpg_alloc+ecpg_add_mem in one call.)
It makes sense.
>> /* Here are some methods used by the lib. */
>>
>> /* Returns a pointer to a string containing a simple type name. */
> That second comment is completely bogus. It's not this patch's fault, it's
> been like that forever, but just happened to notice..
Corrected.
All those things are addressed in the patch attached.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
20150203_ecpg_fix_dereferenced_v2.patch | application/x-patch | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2015-02-03 13:55:11 | Re: Release note bloat is getting out of hand |
Previous Message | Petr Jelinek | 2015-02-03 13:09:21 | Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders |