On Mon, Nov 12, 2018 at 10:27:32AM +0100, Dario Lombardo wrote:
> > 1. I'm not familiar with GDB and could not set a breakpoint in my
> > functions. Is there a trick to it? How do you run it?
>
> What's exactly your issue? When I run
>
> gdb --args run/wireshark
> break filename.c:xxx
>
> I'm asked if I want to set a breakpoint for dynamically loaded library
> (that's the case for dissectors, that live in libwireshark.so).
You won't be asked once the libraries are asked. For that you could
"start" the program first (which will load all libraries and stop at the
main function), set the breakpoints and continue. You could either enter
the commands directly in the gdb shell, or use the `-ex "command"`
option to execute "command" directly. Optionally you can use the `-q`
option to hide the long license prompt:
gdb -q -ex start -ex 'b your_function' -ex c
Further documentation about breakpoints:
https://sourceware.org/gdb/onlinedocs/gdb/Set-Breaks.html
Documentation about "run" and "start":
https://sourceware.org/gdb/onlinedocs/gdb/Starting.html
Additionally, if you rebuild your binaries without restarting GDB, you
might have to reload the debugging information for the executable and
libraries. Run the "file" command first before restarting the program
with "run" (shorthand: "r"):
file run/wireshark
r
> > And a small note:
> > The documentation indicates that you should run `./wireshark` to run the
> > compiled version, whereas it really should be `./run/wireshark`. Same goes
> > for the fuzz-test.sh.
> >
> > https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcRunFirstTime.html#ChSrcRunFirstTimeUnix
> > Not a big deal, but that was the only non-smooth part of the compilation
> > process :)
> >
>
> Ok, I'll take them from here.
Thomas, if you spot possible improvements for the WSDG, feel free to
send a patch for it. The sources are located in docbook/wsdg_src, it can
be built with:
ninja developer_guides
and the result will be located in your build directory at
docbook/wsdg_html_chunked/
I have not used fuzz-test.sh yet, so I cannot comment on that. Usually
however you should probably build with some sanitizers enabled:
cmake -DENABLE_ASAN=1 -DENABLE_UBSAN=1
Sanitizers are developed in the LLVM/Clang source tree, so instead of
GCC you could optionally use Clang:
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
While running programs, you could set an extra environment variable to
disable memory leak reporting if you are only interested in preventing
crashes. Additionally, set a variable to make some memory allocators
directly use malloc/free such that the ASAN can carefully track every
allocation:
export ASAN_OPTIONS=detect_leaks=0:abort_on_error=1
export WIRESHARK_DEBUG_WMEM_OVERRIDE=simple G_SLICE=always-malloc
ASAN_OPTIONS is a colon-separated list of options, more can be shown
with the option ASAN_OPTIONS=help=1. abort_on_error=1 is optional, but
recommended if you run with GDB since you can examine the call stack on
errors (e.g. using the "bt" command for a stack trace).
--
Kind regards,
Peter Wu
https://lekensteyn.nl
