If the SSL connection failed before the headers came, we were not
dealing with deallocating the header malloc. This takes care of it.
Using CyaSSL, we are then valgrind-clean for ssl client and server.
With OpenSSL, there is 88 bytes lost at init that never changes or
gets recovered. AFAIK there's nothing to do about that.
OpenSSL also blows these during operation
==1059== Conditional jump or move depends on uninitialised value(s)
==1059== at 0x4A0B131: bcmp (mc_replace_strmem.c:935)
==1059== by 0x3014CDDBA8: ??? (in /usr/lib64/libcrypto.so.1.0.1c)
==1059== by 0x3015430852: tls1_enc (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x3015428CEC: ssl3_read_bytes (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x30154264C5: ??? (in /usr/lib64/libssl.so.1.0.1c)
==1059== by 0x4C3C596: lws_server_socket_service (server.c:153)
==1059== by 0x4C32C1E: libwebsocket_service_fd (libwebsockets.c:927)
==1059== by 0x4C33270: libwebsocket_service (libwebsockets.c:1225)
==1059== by 0x401C84: main (in /usr/bin/libwebsockets-test-server)
However googling around
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/60021http://www.openssl.org/support/faq.html#PROG13
(also the next FAQ down)
it seems OpenSSL have a relaxed attitude to this and it's expected.
It's interesting CyaSSL works fine but doesn't have that problem...
Signed-off-by: Andy Green <andy.green@linaro.org>
CyaSSL blows (symptomless?) uninitialized memory accesses in
valgrind when using SSL_get_version()... don't need to do it...
Signed-off-by: Andy Green <andy.green@linaro.org>
This brings the library sources into compliance with checkpatch
style except for three or four exceptions like WIN32 related stuff
and one long string constant I don't want to break into multiple
sprintf calls.
There should be no functional or compilability change from all
this (hopefully).
Signed-off-by: Andy Green <andy.green@linaro.org>
OpenSSL doesn't seem to have a way to close out three allocations
it creates during SSL library init.
Even after doing the magic incantations suggested on the openssl list, we're
left with these. Well, 88 bytes from ssl init is probably not critical,
but it's annoying
==15206== HEAP SUMMARY:
==15206== in use at exit: 88 bytes in 3 blocks
==15206== total heap usage: 13,566 allocs, 13,563 frees, 5,933,134 bytes allocated
==15206==
==15206== 24 bytes in 1 blocks are still reachable in loss record 1 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441B38: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3014CC91BE: sk_new (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441AF9: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== 32 bytes in 1 blocks are still reachable in loss record 3 of 3
==15206== at 0x4A06409: malloc (vg_replace_malloc.c:270)
==15206== by 0x3014C612B2: CRYPTO_malloc (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3014CC91DC: sk_new (in /usr/lib64/libcrypto.so.1.0.1c)
==15206== by 0x3015441AF9: ??? (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x3015443A78: SSL_COMP_get_compression_methods (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x301544932B: SSL_library_init (in /usr/lib64/libssl.so.1.0.1c)
==15206== by 0x4C340D4: libwebsocket_create_context (libwebsockets.c:1796)
==15206== by 0x401C08: main (in /usr/bin/libwebsockets-test-server)
==15206==
==15206== LEAK SUMMARY:
==15206== definitely lost: 0 bytes in 0 blocks
==15206== indirectly lost: 0 bytes in 0 blocks
==15206== possibly lost: 0 bytes in 0 blocks
==15206== still reachable: 88 bytes in 3 blocks
==15206== suppressed: 0 bytes in 0 blocks
Signed-off-by: Andy Green <andy.green@linaro.org>
This removes all the direct wsi members specific to clients,
most of them are moved to being fake headers in the next 3-layer
header scheme, c_port moves to being a member of the u.hdr
unionized struct.
It gets rid of a lot of fiddly mallocs and frees(), despite it
adds a small internal API to create the fake headers, actually
the patch deletes more than it adds...
Signed-off-by: Andy Green <andy.green@linaro.org>
This seems to be enough to get a clean valgrind run for the
test server with 1 x chrome and 1 x libwebsockets-test-client
session being run for 10s
lwsts[19767]: libwebsockets-test-server exited cleanly
==19767==
==19767== HEAP SUMMARY:
==19767== in use at exit: 0 bytes in 0 blocks
==19767== total heap usage: 41,071 allocs, 41,071 frees, 27,464,834 bytes allocated
==19767==
==19767== All heap blocks were freed -- no leaks are possible
==19767==
==19767== For counts of detected and suppressed errors, rerun with: -v
==19767== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
test client is another story...
Signed-off-by: Andy Green <andy.green@linaro.org>
To get a clean bill of health from valgrind, we have to have a way to
inform the user code that we're going down and it should free everything
it is holding that was malloc'd.
This patch introduces LWS_CALLBACK_PROTOCOL_DESTROY which each protocol
gets when the context is being destroyed and no more activity will come
after that call. They can get rid of everything there.
To match it, LWS_CALLBACK_PROTOCOL_INIT is introduced which would allow
one-time init per protocol too.
Signed-off-by: Andy Green <andy.green@linaro.org>
This big patch replaces the malloc / realloc per header
approach used until now with a single three-level struct
that gets malloc'd during the header union phase and freed
in one go when we transition to a different union phase.
It's more expensive in that we malloc a bit more than 4Kbytes,
but it's a lot cheaper in terms of malloc, frees, heap fragmentation,
no reallocs, nothing to configure. It also moves from arrays of
pointers (8 bytes on x86_64) to unsigned short offsets into the
data array, (2 bytes on all platforms).
The 3-level thing is all in one struct
- array indexed by the header enum, pointing to first "fragment" index
(ie, header type to fragment lookup, or 0 for none)
- array of fragments indexes, enough for 2 x the number of known headers
(fragment array... note that fragments can point to a "next"
fragment if the same header is spread across multiple entries)
- linear char array where the known header payload gets written
(fragments point into null-terminated strings stored in here,
only the known header content is stored)
http headers can legally be split over multiple headers of the same
name which should be concatenated. This scheme does not linearly
conatenate them but uses a linked list in the fragment structs to
link them. There are apis to get the total length and copy out a
linear, concatenated version to a buffer.
Signed-off-by: Andy Green <andy.green@linaro.org>
The idea here seems wrong, if we have a mixture of frames of varying
sizes above and below the limit, we segfault in deflate after skipping
it once.
If the protocol doesn't want compression because many frames are
small, it should veto the extension in the user callback. If only
a few frames are tiny, the overhead for compressing it all is tiny.
Signed-off-by: Andy Green <andy.green@linaro.org>
Now we are building with -O0 -g and debug enabled by default.
--disable-debug in configure will get you a -04 without -g
Signed-off-by: Andy Green <andy.green@linaro.org>
Also max protocols to 5 (overridable by configure) and max extensions
from 10 to 3 by default (also overridable by configure).
wsi is down to 608 on x86_64 with this.
Signed-off-by: Andy Green <andy.green@linaro.org>
As reported here
http://libwebsockets.org/trac/ticket/11
the code for connection storm handling had rotted, fds[0] is no longer
always related to the listen socket when serving.
This patch updates it to determine the listen socket correctly to stop
infinite recursion here.
Reported-by: amn
Signed-off-by: Andy Green <andy.green@linaro.org>
Now we enforce nonblocking everywhere, hopefully properly,
this rx timeout stuff shouldn't be needed.
Signed-off-by: Andy Green <andy.green@linaro.org>
*** This patch changes an API all apps use ***
Context creation parameters are getting a bit out of control, this
patch creates a struct to contain them.
All the test apps are updated accordingly.
Signed-off-by: Andy Green <andy.green@linaro.org>
A new protocol member is defined that controls the size of rx
buffer allocation per connection. For compatibility 0 size
allocates 4096, but you should adapt your protocol definition
array in the user code to declare an appropriate value.
See the changelog for more detail.
The advantage is the rx frame buffer size is now tailored to
what is expected from the protocol, rather than being fixed
to a default of 4096. If your protocol only sends frames of
a dozen bytes this allows you to only allocate an rx frame
buffer of the same size.
For example the per-connection allocation (excluding headers)
for the test server fell from ~4500 to < 750 bytes with this.
Signed-off-by: Andy Green <andy.green@linaro.org>
This gets rid of the stack buffer while serving files, and the
PATH_MAX char array that used to hold the filepath in the wsi.
It holds an extra file descriptor open while serving the file,
however it attempts to stuff the socket with as much of the
file as it can take. For files of a few KB, that typically
completes (without blocking) in the call to
libwebsockets_serve_http_file() and then closes the file
descriptor before returning.
Signed-off-by: Andy Green <andy.green@linaro.org>
This reduces the size of struct libwebscocket from 4840 to 4552
on x86_64
There are also big benefits on malloc pool fragmentation and
allocation, the header allocations only exist between the first
peer communication and websocket connection establishment for
both server and client.
Signed-off-by: Andy Green <andy.green@linaro.org>
