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

Silas Parker skyhisi+libwebsockets at gmail.com
Tue Nov 19 14:11:39 CET 2019


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