Thanks Daniel for the patch for cert_stuff. It seems like the proper
solution. I'll look into taking that direction.
Also, thanks Kamil for the references. I'll need to look there more
carefully. It does seem that the issue boils down to allocations
in pem_CreateObject, and the references to finalize look promising.
I continue to gather more metrics to get a better handle. We expect our
fusedav instance to need about 70M of memory and by running a continual
series of tests overnight can see that extend to 150M, so that's the size
of the problem we are investigating.
Thanks again.
Jerry

On Tue, Aug 20, 2013 at 1:52 AM, Kamil Dudka <kdudka_at_redhat.com> wrote:

> On Tuesday 20 August 2013 10:39:02 Daniel Stenberg wrote:
> > On Mon, 19 Aug 2013, Jerry Blakley wrote:
> > > What seems to be happening is that while the session is open and the
> > > connection reused, we make the repeated allocations in
> nss_create_object,
> > > increasing memory usage, until the session ends and curl_easy_cleanup
> is
> > > called.
> > >
> > > Is this the case, and should it be so? Or is there/should there be some
> > > intermediary cleanup routine, or an ability to reuse the certificate
> > > information without the reallocation?
> >
> > Hi,
> >
> > I'm not an NSS expert but it looks to me like there's no need to reload
> the
> > cert/key when the connection is re-used (as it is only re-used when the
> > same cert/key is set). What about a patch like the attached?
>
> Thanks for the patch! I see cert_stuff() is called only when doing a SSL
> handshake. Can it actually happen that a new handshake is initiated on a
> reused connection?
>
> Kamil
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-08-20