mirror of
https://github.com/warmcat/libwebsockets.git
synced 2025-03-09 00:00:04 +01:00
64 lines
2.3 KiB
Markdown
64 lines
2.3 KiB
Markdown
|
# Tips on debugging with lws
|
||
|
|
|
||
|
|
## Problem with the library, or your code?
|
||
|
|
|
||
|
|
Because lws is only really used when already combined with user code,
|
||
|
|
it can be a headache figuring out if the actual problem is inside lws
|
||
|
|
or in the user code.
|
||
|
|
|
||
|
|
If it's in lws, I would really like to solve it, but if it's in your
|
||
|
|
code, that's your problem. Finding out which side it's on when it
|
||
|
|
involves your code is also something you need to try to resolve.
|
||
|
|
|
||
|
|
The minimal examples are useful because if they demonstrate the same
|
||
|
|
problem, it's something about your platform or lws itself, I have the
|
||
|
|
minimal examples so I can test it and find out if it's your platform.
|
||
|
|
If I can reproduce it, it's my problem.
|
||
|
|
|
||
|
|
## Debug builds
|
||
|
|
|
||
|
|
With cmake, build with `-DCMAKE_BUILD_TYPE=DEBUG` to build in extra
|
||
|
|
logging, and use a log level bitmap of eg, 1039 or 1151 to enable
|
||
|
|
the extra logs for print.
|
||
|
|
|
||
|
|
The minimal examples take a -d xxx commandline parameter so you can
|
||
|
|
select the logging level when you run it.
|
||
|
|
|
||
|
|
The extra logging can be very useful to understand the sequencing of
|
||
|
|
problematic actions.
|
||
|
|
|
||
|
|
## Valgrind
|
||
|
|
|
||
|
|
If your problems involve heap corruption or use-after-free, Valgrind
|
||
|
|
is indespensible. It's simple to use, if you normally run `xxx`, just
|
||
|
|
run `valgrind xxx`. Your code will run slower, usually something
|
||
|
|
like 2 - 4x slower but it depends on the exact code. However you will
|
||
|
|
get a backtrace as soon as there is some kind of misbehaviour of either
|
||
|
|
lws or your code.
|
||
|
|
|
||
|
|
lws is developed using valgrind routinely and strives to be completely
|
||
|
|
valgrind-clean. So typically any problems reported are telling you
|
||
|
|
about problems in user code (or my bugs).
|
||
|
|
|
||
|
|
## Traffic dumping
|
||
|
|
|
||
|
|
The best place for dumping traffic, assuming you are linking against a
|
||
|
|
tls library, is `lws_ssl_capable_read()` and `lws_ssl_capable_write()`
|
||
|
|
in either `./lib/tls/openssl/openssl-ssl.c` or
|
||
|
|
`./lib/tls/mbedtls/mbedtls-ssl.c` according to which tls library you
|
||
|
|
are using. There are default-`#if 0` sections in each function like
|
||
|
|
|
||
|
|
```
|
||
|
|
#if 0
|
||
|
|
/*
|
||
|
|
* If using mbedtls type tls library, this is the earliest point for all
|
||
|
|
* paths to dump what was received as decrypted data from the tls tunnel
|
||
|
|
*/
|
||
|
|
lwsl_notice("%s: len %d\n", __func__, len);
|
||
|
|
lwsl_hexdump_notice(buf, len);
|
||
|
|
#endif
|
||
|
|
```
|
||
|
|
|
||
|
|
Enable these to get hexdumps for all unencrypted data in both directions.
|
||
|
|
|