[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Fri May 13 14:11:50 CEST 2016

On May 13, 2016 7:25:43 PM GMT+08:00, Andrejs Hanins <andrejs.hanins at ubnt.com> wrote:
>On 05/13/2016 01:22 PM, Andy Green wrote:
>> On 05/13/2016 05:36 PM, Andrejs Hanins wrote:
>>> Andy,
>>> On 05/12/2016 10:01 PM, Andy Green wrote:
>>>>> Well, still bad. With current master I can establish client
>>>>> only once. After it is disconnected I try to establish it again,
>>>>> never get any callback back.
>>>>> I will investigate tomorrow in more details. Just to let you know
>- it
>>>>> was absolutely rock solid with 1.7.5, never had any single problem
>>>>> LWS.
>>>> Well, v2.0 test client has no problems making multiple connections.
>>>> V2.0 is v1.7 with some patches.
>>>> There's nothing I can do about 'bad', 'crash', except wonder about
>the code I can't see.
>>> I figured it out why reconnects didn't work for me - I was passing
>two protocols for vhost creation,
>>> as a result failed connection attempts were notified by
>>> for the _first_ protocol (that is Http, array index 0), but my code
>was expecting to get all WS-related
>>> callbacks from the _second_ protocol (array index 1). After I
>removed Http protocol from the vhost
>>> creation everything started to work fine and no more crashes. So
>patch is good, thank you Andy!
>> Good... there are some things that happen before the protocol is
>negotiated with the ws or http server.  Since you may have multiple ws
>protocols listed, there's no way before negotiation to make a sensible
>choice, so they just go on the first one.  Which at least one way or
>the other, can always be counted on to be there; there's no requirement
>to have any second protocol.
>> Likewise some things are global.
>>> But I noticed, that SSL_library_init is called twice - first from
>lws_context_init_ssl_library when I create a
>>> ctx, then from lws_context_init_client_ssl when I call
>> Yes... it's not right.
>>> If I remove LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT from ctx creation,
>then something breaks
>>> internally, incoming/outgoing connections don't work any more and I
>get the following logs:
>> No you want that.
>>> LWS:  forbidding on uri sanitation
>>> LWS: error on reading from skt : 131
>>> LWS: SSL connect error 336031996:
>>> So it looks like in order for the SSL to work it needs to be
>initialized in ctx, but then it is
>>> initialized again due to lws_init_vhost_client_ssl. It doesn't look
>to be causing any
>>> problems, but initializing SSL more than once doesn't look right to
>> Yes it's not needed any more, since after 1.7 the SSL global init got
>cleaned up and always occurs at context creation time now.
>> I pushed a patch on master removing the duplicated init from
>The patch works fine, thanks.
>Still, each creation of ctx calls SSL_library_init. In my code I need
>to recreate the ctx when network configuration
>changes, so SSL_library_init still might be called several times for
>one process. Do you think this is a problem from SSL library design
>point of view?

I see the point, actually I dunno, because openssl and valgrind don't play well together.  Those openssl calls just seem to set statics in the process context, they seem to allocate but don't take any args.

I guess it means add a context creation option flag to defeat the openssl onetime per-process init, and set it in your code for subsequent context creation.  It's probably better than add to the pile of process context variables coming out of a library.

>Are you going to release 2.0.2 soon? If not, I need to stick to some
>master branch git hash.

2.0.1 was only yesterday, let's give it a few days.

Actually I'd like more feedback about any missing bits in the plugins stuff... I plan to add per-vhost additional  file suffix - mime type mappings that the mounts can do themselves, otherwise for my current use-cases it's already enough.  Then I think it needs to head towards 2.1 before too long.


>> -Andy
>>>> -Andy

More information about the Libwebsockets mailing list