[Libwebsockets] valgrind under lwsws

Silas Parker skyhisi+libwebsockets at gmail.com
Wed Aug 23 10:33:54 CEST 2017


On 23 August 2017 at 09:25, Andy Green <andy at warmcat.com> wrote:

>
>
> On 08/23/2017 04:00 PM, Andy Green wrote:
>
>>
>>
>> On 08/23/2017 03:42 PM, Mario Theodoridis wrote:
>>
>>> Hello,
>>>
>>> i'm building a websocket server using the v2.2-stable plugin lwsws libuv
>>> variant.
>>>
>>
>> Okay... you should probably think about v2.3-stable though.  There are no
>> real changes to the API just additions.
>>
>> I noticed that running the server in a debugger didn't work for me, even
>>> when i disabled daemonizing by:
>>>
>>> --- a/lwsws/main.c
>>> +++ b/lwsws/main.c
>>> @@ -237,7 +237,7 @@ int main(int argc, char **argv)
>>>
>>>          fprintf(stderr, "Root process is %u\n", getpid());
>>>
>>> -       while (1) {
>>> +       while (0) {
>>>                  if (do_reload) {
>>>                          do_reload = 0;
>>>                          n = fork();
>>>
>>> I worked around the debugging issue by using logging instead and i'm
>>> fine with that.
>>>
>>
>> When you say, "didn't work", or "debugging issue", what does it mean in
>> practical terms?
>>
>> For gdb, if you start it with
>>
>> $ sudo gdb --args /usr/local/bin/lwsws
>>
>> and then
>>
>> (gdb) set follow-fork-mode child
>> (gdb) r
>>
>> it should be enough.
>>
>> With libuv if you get a segfault or so, started without a debugger, he
>> will spin.  You can attach gdb to it with
>>
>> $ sudo gdb -p <pid>
>>
>> then and get a backtrace etc.  The <pid> should be the lwsws child
>> process pid.
>>
>> Now i'm trying to run the server under valgrind to remove mem leaks.
>>> Unfortunately i get log entries like:
>>>
>>>   268 (12 direct, 256 indirect) bytes in 1 blocks are definitely lost in
>>> loss record 7 of 8
>>>      at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_me
>>> mcheck-x86-linux.so)
>>>      by 0x495BBE2: ???
>>>      by 0x4972281: ???
>>>      by 0x4976320: ???
>>>      by 0x4044868: ???
>>>      by 0x4044BA6: ???
>>>      by 0x4044D58: ???
>>>      by 0x407C6FB: user_callback_handle_rxflow (libwebsockets.c:1223)
>>>      by 0x40860FB: lws_rx_sm (parsers.c:1484)
>>>      by 0x409928C: lws_interpret_incoming_packet (server.c:2554)
>>>      by 0x407A599: lws_read (handshake.c:239)
>>>      by 0x4080865: lws_service_fd_tsi (service.c:1205)
>>>      by 0x4080A90: lws_service_fd (service.c:1328)
>>>      by 0x409D094: lws_io_cb (libuv.c:101)
>>>      by 0x40C6BBE: uv__poll_io (poll.c:51)
>>>      by 0x40D1FB3: uv__io_poll (linux-core.c:400)
>>>      by 0x40BDB3D: uv_run (core.c:362)
>>>      by 0x409DBAD: lws_libuv_run (libuv.c:414)
>>>      by 0x8049496: main (main.c:299)
>>>
>>> And i'm fairly sure that the ??? entries are my plugin.
>>> Both server and plugin are built with the CFLAGS -ggdb3 -O0
>>>
>>
>> If it's gcc and you set your CFLAGS plugin by hand, you are looking for
>> -g and don't strip the ELF.
>>
>
> Sorry I didn't look closely enough at your CFLAGS... you are already doing
> -g.
>
> It looks like debugging dynamically loaded things is a bit fraught.
>
> Gdb wants:
>
> add-symbol-file filename address
>
> which is OK except determining "address".
>
> In (master) libuv.c:562 we use uv_dlsym() to get the user VA for the init
> function.  Maybe it's possible to get the VA for some symbol at +0 and dump
> it (patch very welcome) making it easier to bring in the symbols.
>
> -Andy
>
>
> -Andy
>>
>> What is the best way to get the debug symbols to show up in the valgrind
>>> dump?
>>>
>>> Thanks.
>>>
>>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> https://libwebsockets.org/mailman/listinfo/libwebsockets
>>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets
>

I haven't tried the plugins myself, but you might need the rdynamic link
flag.

-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that support
it. This instructs the linker to add all symbols, not only used ones, to
the dynamic symbol table. This option is needed for some uses of dlopen or
to allow obtaining backtraces from within a program.

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Thanks,
Silas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20170823/95b46def/attachment-0002.html>


More information about the Libwebsockets mailing list