From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Vesa-Matti J Kari <vmkari(at)cc(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Strange hanging bug in a simple milter |
Date: | 2013-09-13 16:40:11 |
Message-ID: | 20130913164011.GR2706@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki, all,
* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> Very curious. Out of time right now to look into it, but will probably
> be back at it later tonight.
Alright, I was back at this a bit today and decided to go with a hunch-
and it looks like I might have been right to try.
Leaving the locking callback hooks in place appears to prevent the
deadlocks from happening, at least with this little app.
IOW, in destroy_ssl_system(), simply arrange to not have
CRYPTO_set_locking_callback(NULL); and CRYPTO_set_id_callback(NULL);
called. I've done this with the very simple attached patch. Per the
comment above destroy_ssl_system(), this doesn't seem to be an
acceptable solution because libpq might get unloaded from the
application, but perhaps it points the way towards what the issue is.
My thought had been that there was an issue with regard to signal
handling, but I've been unable to confirm that, nor is it clear why that
would be the case. In any case, I'm curious what others think of these
results and if anyone can reproduce the deadlock with this patch
applied.
Thanks!
Stephen
Attachment | Content-Type | Size |
---|---|---|
dont_drop_hooks.patch | text/x-diff | 1.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-09-13 17:00:49 | Re: Strange hanging bug in a simple milter |
Previous Message | Andres Freund | 2013-09-13 16:34:54 | Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers |