[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Fri May 13 15:20:15 CEST 2016



On May 13, 2016 9:05:05 PM GMT+08:00, Jaco Kroon <jaco at uls.co.za> wrote:
>Hi,
>
>I hate saying this, but perhaps you just need to keep a static variable
>(false default) to indicate if you've already called init.

Maybe.... but if the context destroy stuff does actually undo everything from the context create (you'd certainly want it to, and it looks like it tries to do that, but the openssl api names are confusing) then we don't need anything except destroy the old context before we create the new one.

And this is all completely specific to openssl and exact clones.

-Andy

>Kind Regards,
>Jaco Kroon
>
>
>On 13/05/2016 14:52, Andy Green wrote:
>>
>> On May 13, 2016 8:40:45 PM GMT+08:00, Andrejs Hanins
><andrejs.hanins at ubnt.com> wrote:
>>>
>>> On 05/13/2016 03:11 PM, Andy Green wrote:
>>>> 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.
>>> If you mean LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT to be set only for
>the
>>> first ctx creation, then it doesn't work either,I tried it already.
>> No I mean a new flag to act as a hint that this isn't the first
>context creation with ssl enabled for this process.  Then we skip doing
>the static init actions in context create.
>>
>> I'll look further into it tomorrow, because it seems openssl fixed
>this strange init business on 1.1.0 with an alternate api
>OPENSSL_init_ssl()
>>
>> https://www.openssl.org/docs/manmaster/ssl/OPENSSL_init_ssl.html
>>
>> But eg fedora is still on 1.0.1.  But I am wondering if what we doin
>destroy context for ssltakedownis already enough.
>>
>> -Andy
>>
>>> After the ctx is destroyed and created again without this flag then
>>> nothing works well and crashes after some time. I suppose because
>this
>>> flag affects not only SSL_library_init, but also
>>> OpenSSL_add_all_algorithms, SSL_load_error_strings and
>>> SSL_CTX_get_ex_new_index, but ctx destroy calls
>lws_ssl_context_destroy
>>> always. In other words, init is done once, but deinit every time
>when
>>> ctx is destroyed.
>>>>> 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.
>>> Ok, I'll wait. No prob.
>>>> 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
>>>>
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list