[Libwebsockets] v2.0 crashes

Andy Green andy at warmcat.com
Fri May 13 14:52:42 CEST 2016

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()


But eg fedora is still on 1.0.1.  But I am wondering if what we doin destroy context for ssltakedownis already enough.


>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

More information about the Libwebsockets mailing list