[Libwebsockets] valgrind under lwsws

Andy Green andy at warmcat.com
Wed Aug 23 14:38:37 CEST 2017



On 08/23/2017 08:26 PM, Mario Theodoridis wrote:
> Thanks for your quick responses.
> 
> 
> On 23/08/17 10:33, Silas Parker wrote:
>> On 23 August 2017 at 09:25, Andy Green <andy at warmcat.com 
>> <mailto: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.
>>
> 
> Ok, just upgraded to 2.3.
> 
>>
>>             ...
>>             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?
>>
> I'm using gdb under kdevelop, so it's a bit harder to answer that.
> 
>>
>>         For gdb, if you start it with
>>
>>         $ sudo gdb --args /usr/local/bin/lwsws
>>
>>         and then
>>
>>         (gdb) set follow-fork-mode child
>>         (gdb) r
>>
> 
> That just seemed to work, even under kdevelop.
> 
>>
>>         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>
>>
> Thanks, i'll look into that.
> 
>>         ...
>>
>>
>>     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.
>>
> Not sure how to get that. An objdump -d lib.so starts at 0x0f38

That's not what it wants... because it's loaded dynamically, and other 
things may have been loaded before it, the VA it was loaded at in the 
process is not known until it was loaded.

After it's loaded, lws resolves an init function symbol in the 
dynamically loaded library using uv_dlsym().  This address has been 
fixed up with the VA load offset: so if the init function was at the 
load address + 0x678 in the plugin image, uv_dlsym() would return 
something like 0x40f10678, ie, the VA base was 0x40f10000.

If you made sure there was a symbol exported at +0x0 in the image (there 
may already be such a symbol), then the value for that symbol reported 
by uv_dlsym() would be (the VA base + 0x0), ie, the VA base that gdb 
wants to hear about.  You could add a patch to dump that value during 
startup so you know what to give gdb.

>>     ...
>>
>>
>> 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
> 
> 
> Hmm, i tried -dynamic for the plugin as well as lwsws itself. Nothing 
> changed :(
> 
> So it seems, i should be able to debug, but still have the valgrind issue.

Well... valgrind is working fine.  You have a "debug symbols for 
dynamically loaded library" issue, which is not actually something wrong 
with lws.  But it would be nice if we could get lws to print the address 
gdb wants.

-Andy

> 
> -- 
> Mit Freundlichen Grüßen / Regards
> 
> Mario Theodoridis
> 
> regify GmbH
> Römerstrasse 39 | D-78183 Hüfingen
> Amtsgericht Freiburg HRB 709343
> Telefon: +49 771 8978 4238
> 
> 
> 
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets
> 



More information about the Libwebsockets mailing list