[Libwebsockets] Integer truncation in automatic setting of max_http_header_pool

Brice Hamon brice at ydotm.com
Tue Jun 19 20:11:42 CEST 2018


Sorry Andy,

Please ignore the second question.

I forgot how the poll hooked work and the library is served automatically
when there is an event on the fd, so there is no need to call it in the
callback_http.

Sorry about that.

Thank you,
Brice.

On Tue, Jun 19, 2018 at 2:03 PM, Brice Hamon <brice at ydotm.com> wrote:

> Hi Andy,
>
> I just have 2 quick questions.
>
> I finally used the client side of libwebsocket, with external epoll
> support. So far I had the server side working with great success.
> I can connect successfully and all the FD events are managed correctly.
>
> Now my questions:
>
> 1) I am getting notified in the callback with LWS_CALLBACK_GET_THREAD_ID
> every 30 seconds. I return the my thread id but it keeps asking for it. Is
> this a normal condition?
>
> 2) On what event should I call lws_service(wsicont, 1000) for the library
> to be happy?
> I currently call it only on the LWS_CALLBACK_CLIENT_WRITEABLE event.
> Should I do something else?
>
> Thank you,
> Brice.
>
>
>
>
>
> On Tue, Jun 19, 2018 at 5:36 AM, Silas Parker <
> skyhisi+libwebsockets at gmail.com> wrote:
>
>> Thanks Andy, that's great.
>> On Tue, 19 Jun 2018 at 10:17, Andy Green <andy at warmcat.com> wrote:
>> >
>> >
>> >
>> > On 06/19/2018 05:12 PM, Silas Parker wrote:
>> > > Hi Andy,
>> > >
>> > > Just tracked down an issue that was preventing a custom libwebsockets
>> > > based server from working under Docker.
>> > >
>> > > If max_http_header_pool (short int) is zero in the context creation
>> > > info, it takes the value from max_fds (int), and max_fds under Docker
>> > > was being set to 1048576 (0x100000), rather than 1024 like normal, so
>> > > it was being converted to 0 when assigned to max_http_header_pool.
>> > >
>> > > I think the fix would be to either increase the width of
>> > > max_http_header_pool to an int, or to saturate the assignment. The
>> > > following diff is the saturation fix (assuming a short is 2 bytes):
>> > >
>> > > diff --git a/lib/core/context.c b/lib/core/context.c
>> > > index 07f931c3..ebcd16af 100644
>> > > --- a/lib/core/context.c
>> > > +++ b/lib/core/context.c
>> > > @@ -1377,7 +1377,7 @@ lws_create_context(const struct
>> > > lws_context_creation_info *info)
>> > >                          context->max_http_header_pool =
>> > >                                          info->max_http_header_pool2;
>> > >                  else
>> > > -                       context->max_http_header_pool =
>> context->max_fds;
>> > > +                       context->max_http_header_pool =
>> > > context->max_fds > 32767 ? 32767 : context->max_fds;
>> > >
>> > >          if (info->fd_limit_per_thread)
>> > >                  context->fd_limit_per_thread =
>> info->fd_limit_per_thread;
>> >
>> > There's already a fix in master
>> >
>> > https://libwebsockets.org/git/libwebsockets/commit/?id=80d2a
>> bc1fbe2e654ad90eb9cfd333d4f949e5443
>> >
>> > and v3.0-stable
>> >
>> > https://libwebsockets.org/git/libwebsockets/commit/?h=v3.0-s
>> table&id=bdedd1a910106af02dc7c24b5a91faa013b6c763
>> >
>> > since a few hours ago, after a dude on github found the same thing last
>> > night (but wrt running lws under IDE debugging, which causes huge uname
>> -r)
>> >
>> > -Andy
>> >
>> > > Thanks,
>> > > Silas
>> > > _______________________________________________
>> > > Libwebsockets mailing list
>> > > Libwebsockets at ml.libwebsockets.org
>> > > https://libwebsockets.org/mailman/listinfo/libwebsockets
>> > >
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20180619/2a43ccd8/attachment-0002.html>


More information about the Libwebsockets mailing list