Re: Strange hanging bug in a simple milter

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(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 17:59:54
Message-ID: 20130913175954.GV2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2013-09-13 13:15:34 -0400, Stephen Frost wrote:
> > Good thought. Got sucked into a meeting but once I'm out I'll try having
> > the lock/unlock routines abort if they're called while ssl_open_connections
> > is zero, which should not be happening, but seems like it is.
>
> Hm. close_SSL() first does pqsecure_destroy() which will unset the
> callbacks, and the count and then goes on to do X509_free() and
> ENGINE_finish(), ENGINE_free() if either is used.
>
> It's not implausible that one of those actually needs locking. I doubt
> engines play a role here, but, without having looked at the testcase,
> X509_free() might be a possibility.

Unfortunately, while I can still easily get the deadlock to happen when
the hooks are reset, the hooks don't appear to ever get called when
ssl_open_connections is set to zero. You have a good point about the
additional SSL calls after the hooks are unloaded though, I wonder if
holding the ssl_config_mutex lock over all of close_SSL might be more
sensible..

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-09-13 18:30:39 Re: Strange hanging bug in a simple milter
Previous Message Andres Freund 2013-09-13 17:25:20 Re: Strange hanging bug in a simple milter