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

Andy Green andy at warmcat.com
Tue Nov 19 14:57:25 CET 2019



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
>>


More information about the Libwebsockets mailing list