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

Gilles Printemps gprintemps at gmail.com
Tue Nov 19 14:42:44 CET 2019


Hi Silas,
You're right - Fixing this warning resolved the issue with the -02 flag
Is it possible for you to provide details and to explain why the missing
statement (return 0) is producing this behaviour (lws callback called many
times after the destroy with bad parameters) ?

>>> Reason [65535] wsi [(nil)] session [0xa1f4f25cc05cbb00] data [(nil)]
Reason [65535] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
Reason [1706065] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
Reason [1706065] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
Reason [1706065] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
Reason [1706065] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
Reason [1706065] not handled
>>> Reason [0] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]
>>> Reason [1706065] wsi [(nil)] session [0xa1f4f25cc05cbb00] data
[0xffff8a0388c0]


I tried with a lot compiler and confirm it is working without the return
statement

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.12'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)


Thanks for your help but now, as mentioned, I would like to understand...

On Tue, Nov 19, 2019 at 2:11 PM Silas Parker <
skyhisi+libwebsockets at gmail.com> wrote:

> If you compile your code with warnings on, you should see the following:
> Main.cpp: In function ‘void* waitingLoop(void*)’:
> Main.cpp:11:1: warning: no return statement in function returning
> non-void [-Wreturn-type]
>    11 | }
>       | ^
>
> If you add a "return 0;" to your thread function, then it'll work.
> It's nothing to do with libwebsockets.
>
> If you use Compiler Explorer, you can see that modern versions of GCC
> won't generate the ret instruction if you forget to put the return
> statement in your code when optimisations are enabled.
> https://gcc.godbolt.org/z/sk8B-U
>
> Thanks,
> Silas
>
> On Tue, 19 Nov 2019 at 12:43, Gilles Printemps <gprintemps at gmail.com>
> wrote:
> >
> > 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
> >> >
> >
> > _______________________________________________
> > Libwebsockets mailing list
> > Libwebsockets at ml.libwebsockets.org
> > https://libwebsockets.org/mailman/listinfo/libwebsockets
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20191119/f8c60b8b/attachment-0001.htm>


More information about the Libwebsockets mailing list