Re: Strange hanging bug in a simple milter

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Vesa-Matti J Kari <vmkari(at)cc(dot)helsinki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Strange hanging bug in a simple milter
Date: 2013-09-13 19:41:09
Message-ID: 20130913194109.GC2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Heikki Linnakangas (hlinnakangas(at)vmware(dot)com) wrote:
> Actually, I think there's a pre-existing bug there in git master. If
> the SSL_set_app_data or SSL_set_fd call in pqsecure_open_client
> fails for some reason, it will call close_SSL() with conn->ssl
> already set, and the mutex held. close_SSL() will call
> pqsecure_destroy()->destroy_SSL()->destory_ssl_system(), which will
> try to acquire the mutex again.

Yeah, good point, and that one looks like my fault. Moving it after the
unlock should address that tho, no? Looking through the other
close_SSL() calls, I don't see any other situations where it might be
called with the lock held.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-09-13 19:55:16 Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Josh Berkus 2013-09-13 19:36:58 Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers