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

Gilles Printemps gprintemps at gmail.com
Wed Nov 20 10:49:45 CET 2019


Thanks Silas for your explanation.
I was aware about this warning (I'm compiling with -Wall flag) but I was
not thinking it may have a so big impact and be the cause of this issue.
Nevertheless, because I'm not able to follow carefully the
compiler implementations (I'm working in a far way area), I know now that
fixing warnings is a pre-requisite before anything - We learning's new
things everyday...

Thanks again / Best Regards


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

> Hi Gilles,
>
> The missing statement has triggered "undefined behaviour", this means
> the compiler may generate no code, "bad" code, or anything else it
> likes.
>
> In the C++ specification section 6.6.3 "The return statement" it says:
> "Flowing off the end of a function is equivalent to a return with no
> value; this results in undefined behavior in a value-returning
> function."
>
> If you've declared that a function returns a value, but then don't
> return one, what should the compiler generate? The function that
> called it needs a value, so what should it use?
>
> Even with optimisation disabled (-O0) the compiler generates different
> code depending on if the return statement is present. Without the
> return, it generates the "ret", but it doesn't set the EAX register
> (the register used for return values), so the return value from the
> function would be whatever junk had been previously left in EAX by
> other code. When in -O2, it just omits the "ret" completely as
> mentioned previously.
>
> The behaviour with the LLVM compiler is similar to GCC, the MSVC
> compiler refuses to generate code. Have a play around in Compiler
> Explorer which I linked to before, it's very interesting to see what
> C/C++ code turns into at the assembly level.
>
> Thanks,
> Silas
>
> On Tue, 19 Nov 2019 at 13:57, Andy Green <andy at warmcat.com> wrote:
> >
> >
> >
> > On November 19, 2019 1:42:44 PM GMT, Gilles Printemps <
> gprintemps at gmail.com> wrote:
> > >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
> >
> > It's great Silas figured it out.
> >
> > It's blowing a warning telling you to return something IIUI... if it
> empirically "worked" it's just by accident of what was on the stack or in a
> register by chance.  The big lesson to be had here to save yourself next
> time is not exact details of how that trashed parameters to subsequent
> calls, but "build your stuff with -Werror (like lws does) and understand
> what was behind every warning".
> >
> > -Andy
> >
> > >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/20191120/5cee87e8/attachment-0001.htm>


More information about the Libwebsockets mailing list