[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Thu May 12 12:50:46 CEST 2016



On 05/12/2016 06:01 PM, Andrejs Hanins wrote:
> Hi Andy,
>
> On 05/12/2016 12:05 PM, Andy Green wrote:
>>
>>
>> On 05/12/2016 04:38 PM, Andrejs Hanins wrote:
>>> Hi,
>>>
>>> Just updated to v2.0 and got crashes. The first one I figured
>>> out myself - it was necessary to add
>>> LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT option to ctx. Not sure
>>> whether it supposed to crash without this option...
>>
>> People were complaining that lws always initialized SSL libs if
>> linked to them... it blows up valgrind due to some mysterious,
>> hopelessly inextricable incompatibility between at least OpenSSL
>> and valgrind.  So this option was added (in the examples too) so
>> that only if we explicitly want to use SSL does it get
>> initialized.
>>
>> And it's item #2 in the changelog summary.
> Yeah, my bad. I was confused by a crash. So there is no any way to
> see if SSL was initialized outside of LWS and don't try to call any
> SSL API if init wasn't done? Anyway, this is not very important,
> because user error here leads to a guaranteed crash thus will be
> fixed before code gets to the end-user :)

Examples of how to do it are in the test server and client.

>>> But the second one is more tricky - I get NULL context in
>>> lws_ssl_server_name_cb from SSL_CTX_get_ex_data. Any ideas? FYI -
>>> I create two lws contexts inside the process - one for server and
>>> one for client. Before v2.0 everything worked rock solid.
>>
>> Yes: don't use two contexts.
>>
>> Use one context, you can mix client and server connections in the
>> one context just fine.
>>
>> Indeed you can have multiple (serving) vhosts and multiple client
>> connections just fine in one context.
> Ok, please correct my understanding: if I have one server ctx with a
> non-zero port, then default vhost is created but the ssl_client_ctx
> for that vhost is not created, thus when trying to create a client
> connection from this ctx leads to a crash (null ptr dereference). So
> the proper solution is to crate a _client_ ctx first (with empty port
> so that ssl_client_ctx is created), and then add a vhost using
> lws_create_vhost with a port to listen?

Basically the SSL init code still thinks it should init things to be 
either for server or client.

int lws_context_init_client_ssl(struct lws_context_creation_info *info,
			        struct lws_vhost *vhost)
{
...

	if (info->port != CONTEXT_PORT_NO_LISTEN)
		return 0;

However everything else already doesn't distinguish between the two 
uses, before v2.0 http proxying is already working (which binds an 
onward client connection to an accepted server client).  But that was 
only tested on http, not with SSL.

At any rate, for sure the way forward is you should only use one context 
( == one event loop) for all your activities.  If there are still 
problems with that, I will fix them.

It seems the first step is adding a protocol plugin that opens a client 
connection back to his own server.

-Andy

>>
>> -Andy
>>
>>> My compile options are:
>>>
>>> CMAKE_OPTIONS += -DLWS_WITHOUT_TESTAPPS=ON CMAKE_OPTIONS +=
>>> -DCMAKE_BUILD_TYPE=DEBUG CMAKE_OPTIONS +=
>>> -DLWS_WITHOUT_EXTENSIONS=ON CMAKE_OPTIONS += -DLWS_MAX_SMP=1
>>> CMAKE_OPTIONS += -DLWS_OPENSSL_CLIENT_CERTS=/etc/ssl/certs
>>> CMAKE_OPTIONS += -DLWS_OPENSSL_SUPPORT=ON CMAKE_OPTIONS +=
>>> -DLWS_WITH_SSL=ON
>>>
>>> BR, Andrey
>>>
>>> On 05/05/2016 05:20 AM, Andy Green wrote:
>>>> Hi -
>>>>
>>>> Libwebsockets v2.0 is out.
>>>>
>>>> The site is updated
>>>>
>>>> https://libwebsockets.org/
>>>>
>>>> as is the page about v2.0 new features
>>>>
>>>> https://libwebsockets.org/lws-2.0-new-features.html
>>>>
>>>> and the changelog
>>>>
>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog
>>>>
>>>>
>>>>
>>
>>>>
I replaced apache for my web services some weeks ago and have been using 
lwsws (the new generic webserver wrapper on lws) instead, you can see 
the new server status page here
>>>>
>>>> https://libwebsockets.org/server-status/
>>>>
>>>> This is an included lws protocol plugin, although you would
>>>> probably want to put it on a vhost mapped to localhost
>>>> interface only.
>>>>
>>>>
>>>> Basically the theme of the release is eliminate server
>>>> boilerplate code and use plugins for ws protocols.  With this
>>>> method, the test server is reduced to one short file with no
>>>> protocols or user callback.
>>>>
>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/test-server/test-server-v2.0.c
>>>>
>>>>
>>>>
>>
>>>>
If you use lwsws, the generic webserver wrapper which uses JSON config 
files, you can even eliminate the above code as well.
>>>>
>>>> https://github.com/warmcat/libwebsockets/blob/v2.0-stable/README.lwsws.md
>>>>
>>>>
>>>>
>>
>>>>
Protocol plugins can be be easily built against lws out-of-tree
>>>>
>>>> https://github.com/warmcat/libwebsockets/tree/v2.0-stable/plugin-standalone
>>>>
>>>>
>>>>
>>
>>>>
and distributed in their own directories, lws scans in a given list of 
directories for them at startup (and for lwsws, that list is gleaned 
from JSON config fragments in a conf.d/)
>>>>
>>>> In addition to passing the usual Travis + Appveyor it's checked
>>>> on Coverity today and is zero defects.
>>>>
>>>> https://scan.coverity.com/projects/warmcat-libwebsockets
>>>>
>>>> Branch v2.0-stable is also set up for the usual ongoing fixes
>>>> while development continues on master.
>>>>
>>>> Enjoy!
>>>>
>>>> -Andy _______________________________________________
>>>> Libwebsockets mailing list Libwebsockets at ml.libwebsockets.org
>>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>
>>> _______________________________________________ Libwebsockets
>>> mailing list Libwebsockets at ml.libwebsockets.org
>>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>>
>



More information about the Libwebsockets mailing list