[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
>connection
>>>>> only once. After it is disconnected I try to establish it again,
>but
>>>>> 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
>with
>>>>> 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
>LWS_CALLBACK_CLIENT_CONNECTION_ERROR
>>> 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
>lws_init_vhost_client_ssl.
>>
>> 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:
>error:140770FC:lib(20):func(119):reason(252)
>>>
>>> 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
>me.
>>
>> 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
>lws_context_init_client_ssl().
>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
>>
>>>> -Andy
>>>>
>>>




More information about the Libwebsockets mailing list