[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:43:15 CET 2019


Hi Andy,
The provided program is even smaller than the supplied minimal examples.
  It is doing nothing except creating a context and destroying it within a
Thread
However, it has something this is not tested in lws samples: It is enclosed
into c++ class
If there is something similar in lws, can you give me a link and I will
check/test it...

On Tue, Nov 19, 2019 at 1:35 PM Andy Green <andy at warmcat.com> wrote:

>
>
> On 11/19/19 12:27 PM, Gilles Printemps wrote:
> > Hi Andy,
> > I tried to reduce to the minimum the program to highlight the issue.
>
> That's not really what I meant... I mean if you build the supplied
> minimal examples, without any of your code, do they also behave like
> this?  You're basically saying it blows up while destroying the context,
> but that does not happen here with the provided examples.
>
> If it happens just with lws code, it sounds like something I will have
> to study.  But if it only happens with your code, it sounds like
> something you need to study.  Valgrind is very useful.
>
> -Andy
>
> > 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
> > <mailto: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/a1586d20/attachment.htm>


More information about the Libwebsockets mailing list