"Andy Green (林安廸)"
andy at warmcat.com
Mon Feb 11 15:08:38 CET 2013
On 11/02/13 18:23, the mail apparently from Jack Mitchell included:
> On 11/02/13 07:04, "Andy Green (林安廸)" wrote:
>> Hi -
>> I pushed a bunch of bloat-reduction patches, the allocation for a
>> websocket with the library built for openssl, client and server and
>> the rest of the stuff defaults, on x86_64, is now only 240 bytes. An
>> extra 1328 is needed during header processing but is freed as soon as
>> that's done.
>> I was curious about memory leaking, so I ran valgrind on both sides.
>> It found a few problems which I also fixed and pushed.
>> Without building for ssl, it's now valgrind-clean on both the test
>> server and client.
>> With SSL, just initializing the library leaks 88 bytes
>> and running it, it claims there's some unitnitialized accesses coming,
>> which cascade into quite a few warnings. I'm unclear whether that's a
>> real problem or some kind of valgrind-noise, sincee there's no symptom
>> and it does not appear without ssl configured.
>> Does anyone have any experience with OpenSSL valgrind complaints or
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
> I've just had a quick browse and some very nice work, well done!
> Unfortuantly, I have no experience with OpenSSl, so cannot be of
Interestingly when I use Joakim's CyaSSL in place of OpenSSL, there's no
problem, test server and client with a chrome session too are both
totally clean with valgrind.
There's more info here
AFAIK there's nothing more to do for OpenSSL + valgrind from our side.
I'll be very interested if anyone sees any funnies with valgrind under
different loads / conditions, bearing in mind OpenSSL is known to blow
3 lost allocations and occasional uninitialized complaints. There are
still 20 mallocs() in the main code + test server, and 2 realloc in the
deflate-frame extension despite a lot got thrown out today.
More information about the Libwebsockets