[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:27:08 CET 2019


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/c29a03c3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.cpp
Type: application/octet-stream
Size: 549 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/c29a03c3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WebSocketServer.cpp
Type: application/octet-stream
Size: 2489 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/c29a03c3/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WebSocketServer.h
Type: application/octet-stream
Size: 566 bytes
Desc: not available
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/c29a03c3/attachment-0002.obj>


More information about the Libwebsockets mailing list