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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe