This should get rid of a valgrind uninitialized report when using extpoll,
and gives a new way to share the poll loop with external sockets.
If a pollfd says it has something, you can just pass it to
libwebsocket_serice_fd() whether it is a socket handled by lws or not.
If it sees it is a lws socket, the traffic will be handled and
pollfd->revents will be zeroed now.
If the socket is foreign to lws, it leaves revents alone. So you can see
if you should service by checking the pollfd revents after letting
lws try to service it.
Signed-off-by: Andy Green <andy.green@linaro.org>
under load, writing packet sizes to the socket that are normally fine
can do partial writes, eg asking to write 4096 may only take 2800 of
it and return 2800 from the actual send.
Until now lws assumed that if it was safe to send, it could take any
size buffer, that's not the case under load.
This patch changes lws_write to return the amount actually taken...
that and the meaning of it becomes tricky when dealing with
compressed links, the amount taken and the amount sent differ. Also
there is no way to recover at the moment from a protocol-encoded
frame only being partially accepted... however for http file send
content it can and does recover now.
Small frames don't have to take any care about it but large atomic
sends (> 2K) have been seen to fail under load.
Signed-off-by: Andy Green <andy.green@linaro.org>
More flexible this way... NULL for the new member means use
the ssl library default set of ciphers, so as long as your info
struct is zerod by bss or memset, you don't need to do anything
about this change unless you want to set the cipher list.
Signed-off-by: Andy Green <andy.green@linaro.org>
While looking at http://libwebsockets.org/trac/ticket/18
noticed the flow for timeout in service_fd will do bad things
if the fd we came to service has timed out. It gets freed and
then "serviced'.
Reported-by: Joakim Soderberg <joakim.soderberg@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
The function has a logical problem when the size of the requested
allocation is 0, it will return NULL which is overloaded as
failure.
Actually the whole function is evil as an api, this patch moves
it out of the public API space and fixes it to return 0 for
success or 1 for fail. Private code does not need to to return
wsi->user_space and public code should only get that from the
callback as discussed on trac recently.
Thanks to Edwin for debugging the problem.
Reported-by: Edwin van den Oetelaar <oetelaar.automatisering@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
Drop the connection during parsing for a few more cases that can't be legit.
Take care about trying to free rxflow_buffer only if we reached a connmode
where it exists
Change behaviour on setting unknown HTTP method to kill connection
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>
