W3C home > Mailing lists > Public > www-lib@w3.org > January to March 2005

Re: SSL Memory Leakage

From: Vic Bancroft <bancroft@america.net>
Date: Sun, 23 Jan 2005 16:05:12 -0500
Message-ID: <41F41188.8010807@america.net>
To: Sandesh Anvekar <sanvekar@controlnet.co.in>
CC: www-lib@w3.org

Sandesh Anvekar wrote:

>    for (;;)
>     {
>      request = HTRequest_new();
>      HTRequest_addConnection(request, "close", "");
>      HTRequest_setOutputFormat(request,WWW_SOURCE);
>        /* Start the load */
>        chunk = HTLoadToChunk(getme, request);
>      if (chunk)
>       HTRequest_setContext(request,chunk);
>      /* Go into the event loop... */
>        //HTEventList_loop(request);
>      sleep(1);
>     }
>  
>
This fragment allocates memory and never frees it.  Notice that in the 
library function, HTRequest_new/0 defined in HTReqMan.c  there is a call 
to  HT_CALLOC/2 . . . You could move the call to HTRequest_new/0 outside 
the loop and make a call to HTRequest_clear/1 or just add 
HTRequest_delete/1 at the bottom of your loop. The intent of using the 
HTRequest_clear/1 call would be avoidance of somewhat expensive create 
and tear down of memory structures.

>BUT the strange part of this is that it happens only if I get 200 as the response. If I request the non existing page ie 404 this behaviour does not repeat. Also this behaviour does not repeat for HTTP requests.
>  
>
Interesting, I imagine there is some cleanup of structures for the error 
situation, or perhaps the easily noticable memory consumption is never 
reached . . . I will try some profiling on the Robot example, now that 
it can make https requests and see if a leakage manifests there as well.

BTW, under fedora core 3 which uses automake version 1.9.2 release 3, 
there are warnings about all underquoted calls to |AC_DEFUN.  |It also 
seems that something in this new configuration chain that breaks 
modules/md5, e.g.,

    make[3]: Entering directory `/home/bancroft/src/libwww/modules/md5'
    if /bin/sh ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H
    -I. -I. -I../.. -g -O2 -Wall -MT md5.lo -MD -MP -MF ".deps/md5.Tpo"
    -c -o md5.lo md5.c; \
    then mv -f ".deps/md5.Tpo" ".deps/md5.Plo"; else rm -f
    ".deps/md5.Tpo"; exit 1; fi
    libtool: unrecognized option `--tag=CC'
    Try `libtool --help' for more information.
    make[3]: *** [md5.lo] Error 1
    make[3]: Leaving directory `/home/bancroft/src/libwww/modules/md5'
    make[2]: *** [install-recursive] Error 1
    make[2]: Leaving directory `/home/bancroft/src/libwww/modules'
    make[1]: *** [install-recursive] Error 1
    make[1]: Leaving directory `/home/bancroft/src/libwww'
    make: *** [install] Error 2

My workaround was to simply change to that directory and repeat the compile step without the --tag=CC option,


    $ /bin/sh ../../libtool --mode=link gcc -g -O2 -Wall -o libmd5.la
    -rpath /usr/local/lib -version-info "1:0:1" md5.lo -ldl
    -L/usr/local/ssl/lib -lssl -lcrypto
    mkdir .libs
    rm -fr .libs/libmd5.la .libs/libmd5.* .libs/libmd5.*
    ar cru .libs/libmd5.a md5.o
    ranlib .libs/libmd5.a
    creating libmd5.la
    (cd .libs && rm -f libmd5.la && ln -s ../libmd5.la libmd5.la)

Has anyone else encountered this ?

more,
l8r,
v

-- 
america sig
Received on Sunday, 23 January 2005 21:05:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:44 GMT