Re: BUG #2246: Bad malloc interactions: ecpg, openssl

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Another approach would be to have PQsetdbLogin build up a conninfo
> string and pass that into connectOptions1 instead of calling
> connectOptions1 with an empty string and then changing the values
> afterwards. That'd probably be too large of a change to get in as a
> bugfix though. An alternative might be to move the pg_fe_getauthname()
> call to connectOptions2 as it's actually a bit more work than one might
> expect and if that can be avoided then that's probably all to the good.

Right offhand I like the idea of pushing it into connectOptions2 --- can
you experiment with that? Seems like there is no reason to call
Kerberos if the user supplies the name to connect as.

> Sorry I don't have a simple answer. :/ In the end it seems like the
> Kerberos libraries should be able to survive Kerberos not being
> configured or whatever is going on to make it try to malloc 0-bytes...

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