On Mon, Nov 12, 2018 at 11:26:54AM +0100, Peter Wu wrote:
> 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
Oops, I meant "Antoine", sorry for the mixup :p
> 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).
And for better stack traces in UBSAN, you can also set:
export UBSAN_OPTIONS=print_stacktrace=1
If you are debugging a memory safety issue where the call stacks are
truncated, you can make these traces more accurate (but slow the program
significantly) with:
ASAN_OPTIONS=...:fast_unwind_on_malloc=0
--
Kind regards,
Peter Wu
https://lekensteyn.nl
