[Libwebsockets] Which are the events received by the callback when "lws_context_destroy" is called

Gilles Printemps gprintemps at gmail.com
Tue Nov 19 13:33:26 CET 2019


Here are the files in an archive

On Tue, Nov 19, 2019 at 1:27 PM Gilles Printemps <gprintemps at gmail.com>
wrote:

> Hi Andy,
> I tried to reduce to the minimum the program to highlight the issue.
> You can find in attachment the 3 files
> Regarding the compilation, flags are the following:
>   CPPFLAGS (Debug): -DDEBUG -g -O0 -fsanitize=address
> -fno-omit-frame-pointer
>   CPPFLAGS (Release): -g -Wall -O2 -Wstrict-aliasing
>   LDFLAGS (Debug): -fsanitize=address
>   LDFLAGS (Release):
>
> FYI, I currently compiling with g++ on Raspberry Pi 4 model B based on
> Ubuntu
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper
> Target: aarch64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 9.2.1-9ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr
> --with-gcc-major-version-only --program-suffix=-9
> --program-prefix=aarch64-linux-gnu- --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libquadmath --disable-libquadmath-support --enable-plugin
> --enable-default-pie --with-system-zlib --with-target-system-zlib=auto
> --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
> --enable-checking=release --build=aarch64-linux-gnu
> --host=aarch64-linux-gnu --target=aarch64-linux-gnu
> Thread model: posix
> gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
>
> Hope it will be useful to find the issue
>
> On Tue, Nov 19, 2019 at 11:44 AM Andy Green <andy at warmcat.com> wrote:
>
>>
>>
>> On 11/19/19 10:30 AM, Gilles Printemps wrote:
>> > Hi,
>> > I would like to understand which events should be received by the
>> > callback when "lws_context_destroy" function is called.
>> >
>> > Currently, in debug mode, I have the following trace:
>> >
>> >     [2019/11/19 10:01:57:4407] I: lws_context_destroy: ctx
>> 0xffff99a03280
>> >     [2019/11/19 10:01:57:4408] I: lws_destroy_event_pipe
>> >     [2019/11/19 10:01:57:4409] I: __lws_close_free_wsi: 0xffff98203500:
>> >     caller: ctx destroy
>> >      >>> Reason [30] wsi [0xffff98203500] session [(nil)] data [(nil)]
>> >      >>> Protocol [0xffff9a202820]
>> >     [2019/11/19 10:01:57:4411] I: lws_vhost_unbind_wsi: vh default:
>> >     count_bound_wsi 0
>> >     [2019/11/19 10:01:57:4412] I: lws_vhost_destroy1
>> >     [2019/11/19 10:01:57:4413] I: lws_context_destroy2: ctx
>> 0xffff99a03280
>> >      >>> Reason [28] wsi [0xffffe73b2750] session [(nil)] data [(nil)]
>> >      >>> Protocol [0xffff9a202820]
>> >     [2019/11/19 10:01:57:4414] I: __lws_vhost_destroy2: 0xffff98203880
>> >     [2019/11/19 10:01:57:4415] I:   __lws_vhost_destroy2: Freeing vhost
>> >     0xffff98203880
>> >     [2019/11/19 10:01:57:4416] I: lws_context_destroy3: ctx
>> >     0xffff99a03280 freed
>> >     WebSocket Server stopped
>> >
>> >
>> > But in release mode (with -O2 optimisation), I have something different
>> > and strange:
>> >
>> >      >>> Reason [1] wsi [0xaaaaedae9eb0] session [(nil)] data [(nil)]
>> >      >>> Protocol [(nil)]
>> >      >>> Reason [-8707407386353682176] wsi [(nil)] session
>> >     [0xffffa4b03928] data [0xffffa431c8c0]
>> >     Segmentation fault (core dumped)
>>
>> Well, wsi shouldn't be NULL.  For the cases where the event is not
>> actually related to a wsi, like a systemwide or vhost related event, lws
>> keeps a fake wsi in the per-thread struct in the context so it can set
>> the content, vhost and maybe the protocol in there and pass that as the
>> wsi for the callback.
>>
>> > It is ending by a segmentation fault because I'm trying to retrieve the
>> > protocol with a wsi which is equal to NULL a the entrance of the
>> callback.
>> >
>> >     int WebSocketServer::callback(struct lws *wsi,enum
>> >     lws_callback_reasons reason,void *session,void *data,size_t len) {
>> >        const struct lws_protocols *protocol=NULL;
>> >        Tools::debug(">>> Reason [%ld] wsi [%p] session [%p] data
>> >     [%p]\n",reason,wsi,session,data);
>> >        Tools::debug(">>> Protocol [%p]\n",lws_get_protocol(wsi));
>> >
>> >   Seem also the reason is wrong!!!
>> >
>> > Where did the strange behavior can come from?
>>
>> Dunno.  Does it exist on the lws minimal examples?
>>
>> What I'd do is run it under valgrind, not so much for the leak detection
>> but it also allows it to spew backtraces as soon as something goes off
>> the rails.
>>
>> -Andy
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/7d96f82b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example.zip
Type: application/zip
Size: 1784 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/7d96f82b/attachment-0001.zip>


More information about the Libwebsockets mailing list