From: | Andrew Klosterman <andrew5(at)ece(dot)cmu(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #2246: Bad malloc interactions: ecpg, openssl |
Date: | 2006-02-14 21:15:17 |
Message-ID: | Pine.LNX.4.53L-ECE.CMU.EDU.0602141612430.29413@blossom.pdl.cmu.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
On Tue, 14 Feb 2006, Andrew Klosterman wrote:
> > We may be spending too much time on this one point --- as long as
> > Kerberos isn't *writing* into the zero-length alloc, there is nothing
> > illegal immoral or fattening about malloc(0). Can you get ElectricFence
> > to not abort right here but continue on to the real problem?
> >
> > regards, tom lane
>
> Doing a "man efence" lets me know that setting the EF_ALLOW_MALLOC_0
> environment variable ought to let the program continue... I'll check into
> that right now!
>
>
> --Andrew J. Klosterman
> andrew5(at)ece(dot)cmu(dot)edu
Well, when ElectricFence is allowed to ignore malloc() of zero bytes, my
program runs like a champ! Might be associated with the replacement
malloc() that it installs to check for bugs, though.
(back to digging some more...)
--Andrew J. Klosterman
andrew5(at)ece(dot)cmu(dot)edu
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Klosterman | 2006-02-14 21:35:28 | Re: BUG #2246: Bad malloc interactions: ecpg, openssl |
Previous Message | Stephen Frost | 2006-02-14 21:10:33 | Re: BUG #2246: Bad malloc interactions: ecpg, openssl |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-02-14 21:17:57 | Re: Patch Submission Guidelines |
Previous Message | Stephen Frost | 2006-02-14 21:10:33 | Re: BUG #2246: Bad malloc interactions: ecpg, openssl |