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: 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

In response to

Responses

Browse pgsql-hackers by date

  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