<div dir="ltr">Hi Andy,<div>The provided program is even smaller than the supplied minimal examples. </div><div>  It is doing nothing except creating a context and destroying it within a Thread</div><div>However, it has something this is not tested in lws samples: It is enclosed into c++ class</div><div>If there is something similar in lws, can you give me a link and I will check/test it...</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2019 at 1:35 PM Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
On 11/19/19 12:27 PM, Gilles Printemps wrote:<br>
> Hi Andy,<br>
> I tried to reduce to the minimum the program to highlight the issue.<br>
<br>
That's not really what I meant... I mean if you build the supplied <br>
minimal examples, without any of your code, do they also behave like <br>
this?  You're basically saying it blows up while destroying the context, <br>
but that does not happen here with the provided examples.<br>
<br>
If it happens just with lws code, it sounds like something I will have <br>
to study.  But if it only happens with your code, it sounds like <br>
something you need to study.  Valgrind is very useful.<br>
<br>
-Andy<br>
<br>
> You can find in attachment the 3 files<br>
> Regarding the compilation, flags are the following:<br>
>    CPPFLAGS (Debug): -DDEBUG -g -O0 -fsanitize=address <br>
> -fno-omit-frame-pointer<br>
>    CPPFLAGS (Release): -g -Wall -O2 -Wstrict-aliasing<br>
>    LDFLAGS (Debug): -fsanitize=address<br>
>    LDFLAGS (Release):<br>
> <br>
> FYI, I currently compiling with g++ on Raspberry Pi 4 model B based on <br>
> Ubuntu<br>
> Using built-in specs.<br>
> COLLECT_GCC=g++<br>
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper<br>
> Target: aarch64-linux-gnu<br>
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu <br>
> 9.2.1-9ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs <br>
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr <br>
> --with-gcc-major-version-only --program-suffix=-9 <br>
> --program-prefix=aarch64-linux-gnu- --enable-shared <br>
> --enable-linker-build-id --libexecdir=/usr/lib <br>
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib <br>
> --enable-nls --enable-bootstrap --enable-clocale=gnu <br>
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes <br>
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object <br>
> --disable-libquadmath --disable-libquadmath-support --enable-plugin <br>
> --enable-default-pie --with-system-zlib --with-target-system-zlib=auto <br>
> --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror <br>
> --enable-checking=release --build=aarch64-linux-gnu <br>
> --host=aarch64-linux-gnu --target=aarch64-linux-gnu<br>
> Thread model: posix<br>
> gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)<br>
> <br>
> Hope it will be useful to find the issue<br>
> <br>
> On Tue, Nov 19, 2019 at 11:44 AM Andy Green <<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a> <br>
> <mailto:<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
>     On 11/19/19 10:30 AM, Gilles Printemps wrote:<br>
>      > Hi,<br>
>      > I would like to understand which events should be received by the<br>
>      > callback when "lws_context_destroy" function is called.<br>
>      ><br>
>      > Currently, in debug mode, I have the following trace:<br>
>      ><br>
>      >     [2019/11/19 10:01:57:4407] I: lws_context_destroy: ctx<br>
>     0xffff99a03280<br>
>      >     [2019/11/19 10:01:57:4408] I: lws_destroy_event_pipe<br>
>      >     [2019/11/19 10:01:57:4409] I: __lws_close_free_wsi:<br>
>     0xffff98203500:<br>
>      >     caller: ctx destroy<br>
>      >      >>> Reason [30] wsi [0xffff98203500] session [(nil)] data<br>
>     [(nil)]<br>
>      >      >>> Protocol [0xffff9a202820]<br>
>      >     [2019/11/19 10:01:57:4411] I: lws_vhost_unbind_wsi: vh default:<br>
>      >     count_bound_wsi 0<br>
>      >     [2019/11/19 10:01:57:4412] I: lws_vhost_destroy1<br>
>      >     [2019/11/19 10:01:57:4413] I: lws_context_destroy2: ctx<br>
>     0xffff99a03280<br>
>      >      >>> Reason [28] wsi [0xffffe73b2750] session [(nil)] data<br>
>     [(nil)]<br>
>      >      >>> Protocol [0xffff9a202820]<br>
>      >     [2019/11/19 10:01:57:4414] I: __lws_vhost_destroy2:<br>
>     0xffff98203880<br>
>      >     [2019/11/19 10:01:57:4415] I:   __lws_vhost_destroy2: Freeing<br>
>     vhost<br>
>      >     0xffff98203880<br>
>      >     [2019/11/19 10:01:57:4416] I: lws_context_destroy3: ctx<br>
>      >     0xffff99a03280 freed<br>
>      >     WebSocket Server stopped<br>
>      ><br>
>      ><br>
>      > But in release mode (with -O2 optimisation), I have something<br>
>     different<br>
>      > and strange:<br>
>      ><br>
>      >      >>> Reason [1] wsi [0xaaaaedae9eb0] session [(nil)] data [(nil)]<br>
>      >      >>> Protocol [(nil)]<br>
>      >      >>> Reason [-8707407386353682176] wsi [(nil)] session<br>
>      >     [0xffffa4b03928] data [0xffffa431c8c0]<br>
>      >     Segmentation fault (core dumped)<br>
> <br>
>     Well, wsi shouldn't be NULL.  For the cases where the event is not<br>
>     actually related to a wsi, like a systemwide or vhost related event,<br>
>     lws<br>
>     keeps a fake wsi in the per-thread struct in the context so it can set<br>
>     the content, vhost and maybe the protocol in there and pass that as the<br>
>     wsi for the callback.<br>
> <br>
>      > It is ending by a segmentation fault because I'm trying to<br>
>     retrieve the<br>
>      > protocol with a wsi which is equal to NULL a the entrance of the<br>
>     callback.<br>
>      ><br>
>      >     int WebSocketServer::callback(struct lws *wsi,enum<br>
>      >     lws_callback_reasons reason,void *session,void *data,size_t<br>
>     len) {<br>
>      >        const struct lws_protocols *protocol=NULL;<br>
>      >        Tools::debug(">>> Reason [%ld] wsi [%p] session [%p] data<br>
>      >     [%p]\n",reason,wsi,session,data);<br>
>      >        Tools::debug(">>> Protocol [%p]\n",lws_get_protocol(wsi));<br>
>      ><br>
>      >   Seem also the reason is wrong!!!<br>
>      ><br>
>      > Where did the strange behavior can come from?<br>
> <br>
>     Dunno.  Does it exist on the lws minimal examples?<br>
> <br>
>     What I'd do is run it under valgrind, not so much for the leak<br>
>     detection<br>
>     but it also allows it to spew backtraces as soon as something goes off<br>
>     the rails.<br>
> <br>
>     -Andy<br>
> <br>
</blockquote></div>