[Libwebsockets] valgrind under lwsws

Andy Green andy at warmcat.com
Wed Aug 23 10:25:13 CEST 2017



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



More information about the Libwebsockets mailing list