<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Andy,<div>I tried to reduce to the minimum the program to highlight the issue.</div><div>You can find in attachment the 3 files</div><div>Regarding the compilation, flags are the following:</div><div>  CPPFLAGS (Debug): -DDEBUG -g -O0 -fsanitize=address -fno-omit-frame-pointer</div><div>  CPPFLAGS (Release): -g -Wall -O2 -Wstrict-aliasing</div><div>  LDFLAGS (Debug): -fsanitize=address</div><div>  LDFLAGS (Release):  </div><div><br></div><div>FYI, I currently compiling with g++ on Raspberry Pi 4 model B based on Ubuntu</div><div>Using built-in specs.</div><div>COLLECT_GCC=g++</div><div>COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper</div><div>Target: aarch64-linux-gnu</div><div>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</div><div>Thread model: posix</div><div>gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)</div><div><br></div><div>Hope it will be useful to find the issue</div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2019 at 11:44 AM 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 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 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: 0xffff98203500:<br>
>     caller: ctx destroy<br>
>      >>> Reason [30] wsi [0xffff98203500] session [(nil)] data [(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 0xffff99a03280<br>
>      >>> Reason [28] wsi [0xffffe73b2750] session [(nil)] data [(nil)]<br>
>      >>> Protocol [0xffff9a202820]<br>
>     [2019/11/19 10:01:57:4414] I: __lws_vhost_destroy2: 0xffff98203880<br>
>     [2019/11/19 10:01:57:4415] I:   __lws_vhost_destroy2: Freeing 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 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, 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 retrieve the <br>
> protocol with a wsi which is equal to NULL a the entrance of the callback.<br>
> <br>
>     int WebSocketServer::callback(struct lws *wsi,enum<br>
>     lws_callback_reasons reason,void *session,void *data,size_t 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 detection <br>
but it also allows it to spew backtraces as soon as something goes off <br>
the rails.<br>
<br>
-Andy<br>
</blockquote></div>